{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-149-generic", "linux-modules-6.8.0-149-generic" ], "removed": [ "linux-image-6.8.0-147-generic", "linux-modules-6.8.0-147-generic" ], "diff": [ "ca-certificates", "linux-image-virtual" ] } }, "diff": { "deb": [ { "name": "ca-certificates", "from_version": { "source_package_name": "ca-certificates", "source_package_version": "20260816ubuntu0.24.04.1", "version": "20260816ubuntu0.24.04.1" }, "to_version": { "source_package_name": "ca-certificates", "source_package_version": "20260816ubuntu0.24.04.2", "version": "20260816ubuntu0.24.04.2" }, "cves": [], "launchpad_bugs_fixed": [ 2061817 ], "changes": [ { "cves": [], "log": [ "", " * Run update-ca-certificates synchronously with hooks enabled during", " postinst configure so additions and removals are not lost before hooks", " run (LP: #2061817, Debian #1069251).", " * Forward --fresh to hook scripts, allowing ca-certificates-java to request", " a full reconciliation (Debian #866670).", " * Break ca-certificates-java versions older than the trigger-safe 20210218", " hook implementation.", " * Remove a stale deterministic temporary bundle before rebuilding it.", " * Document hook stdin, --fresh forwarding, and add-before-remove ordering.", "" ], "package": "ca-certificates", "version": "20260816ubuntu0.24.04.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2061817 ], "author": "Vyom Yadav ", "date": "Mon, 02 Nov 2026 13:36:02 -0600" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-149.149", "version": "6.8.0-149.149" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-149.149", "" ], "package": "linux-meta", "version": "6.8.0-149.149", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Fri, 23 Oct 2026 14:13:38 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-148.148", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.8.0-148.148", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Fri, 09 Oct 2026 18:15:32 +0300" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-149-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-147.147", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-149.149", "version": "6.8.0-149.149" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-149.149", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-149.149", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Fri, 23 Oct 2026 14:13:08 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-148.148", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-148.148", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Fri, 09 Oct 2026 18:16:01 +0300" } ], "notes": "linux-image-6.8.0-149-generic version '6.8.0-149.149' (source package linux-signed version '6.8.0-149.149') was added. linux-image-6.8.0-149-generic version '6.8.0-149.149' has the same source package name, linux-signed, as removed package linux-image-6.8.0-147-generic. As such we can use the source package version of the removed package, '6.8.0-147.147', 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-6.8.0-149-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-149.149", "version": "6.8.0-149.149" }, "cves": [ { "cve": "CVE-2026-63974", "url": "https://ubuntu.com/security/CVE-2026-63974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2024-50169", "url": "https://ubuntu.com/security/CVE-2024-50169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Update rx_bytes on read_skb() Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt() calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after vsock_transport::read_skb(). While here, also inform the peer that we've freed up space and it has more credit. Failing to update rx_bytes after packet is dequeued leads to a warning on SOCK_STREAM recv(): [ 233.396654] rx_queue is empty, but rx_bytes is non-zero [ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2026-98375", "url": "https://ubuntu.com/security/CVE-2026-98375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.", "cve_priority": "low", "cve_public_date": "2026-10-09 08:16:00 UTC" }, { "cve": "CVE-2026-97567", "url": "https://ubuntu.com/security/CVE-2026-97567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: prevent race between disconnect() and rtx Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93179", "url": "https://ubuntu.com/security/CVE-2026-93179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89527", "url": "https://ubuntu.com/security/CVE-2026-89527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Use svc_xprt_put to free listener on create failure svc_rdma_create() calls kfree(cma_xprt) when svc_rdma_create_listen_id() fails. svc_xprt_init() has already acquired a net namespace reference via get_net_track(); kfree bypasses svc_xprt_free() which releases it. Replace the kfree() with svc_xprt_put() so the kref_init birth reference drops to zero and svc_xprt_free() dispatches svc_rdma_free() to clean up properly. sc_cm_id is still NULL at that point; the preceding patch added the necessary NULL guard in svc_rdma_free(). svc_xprt_free() also drops the module reference via module_put(), but the caller _svc_xprt_create() does the same on xpo_create failure, double-putting the single try_module_get() it acquired. Take a compensating __module_get() before the svc_xprt_put() to keep the count balanced, matching the convention in svc_rdma_accept()'s error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89912", "url": "https://ubuntu.com/security/CVE-2026-89912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38204", "url": "https://ubuntu.com/security/CVE-2025-38204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds read in add_missing_indices stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error.", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-40158", "url": "https://ubuntu.com/security/CVE-2025-40158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU in ip6_output() Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF. We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-93243", "url": "https://ubuntu.com/security/CVE-2026-93243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: properly account locked pages secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89638", "url": "https://ubuntu.com/security/CVE-2026-89638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode. Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case: \t/* skip mode change if it's just for clearing setuid/setgid */ \tif (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) \t\tattrs->ia_valid &= ~ATTR_MODE; This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway. However, with the \"cifsacl\" or \"modefromsid\" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo(). In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write. This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution. Fix this in two places: 1. cifs_setattr_nounix(): only take the \"skip mode change\" shortcut when the mode is emulated via the DOS read-only attribute (i.e. neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are in effect), so that the cleared mode is propagated to the server in the ACL / POSIX cases. 2. cifs_setattr_unix(): this function is only called when Unix extensions are in effect, so the mode is always stored on the server. Remove the shortcut entirely so that the cleared mode is always pushed.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90146", "url": "https://ubuntu.com/security/CVE-2026-90146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, xdp: move offload check into dev_xdp_install() bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: \"ip link set xdp\" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-97558", "url": "https://ubuntu.com/security/CVE-2026-97558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix cifsFileInfo reference leak in deferred close When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89633", "url": "https://ubuntu.com/security/CVE-2026-89633", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The \"validate target area\" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-97559", "url": "https://ubuntu.com/security/CVE-2026-97559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fail DACL rewrite when the new DACL exceeds 64K replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97566", "url": "https://ubuntu.com/security/CVE-2026-97566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97594", "url": "https://ubuntu.com/security/CVE-2026-97594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() runs, and the former parent can then be removed and freed while the hook walks it. A process can trigger this after entering a Landlock domain that handles at least one filesystem access right. The process can then race a linkat(2) loop against rename(2) and rmdir(2): BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collect_domain_accesses+0x278/0x290 current_check_refer_path+0x952/0x1120 security_path_link+0x1be/0x320 filename_linkat+0x342/0x6d0 __x64_sys_linkat+0xfa/0x150 Freed by task 562: kmem_cache_free+0x139/0x4c0 i_callback+0x4b/0x80 rcu_core+0x7dc/0x10a0 Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging. [mic: Clarify the caller, reachability, and reference handling]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97597", "url": "https://ubuntu.com/security/CVE-2026-97597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97609", "url": "https://ubuntu.com/security/CVE-2026-97609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: prevent UAF during module unload nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get() nfct_timeout_pernet() The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported: BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get Read of size 8 by task poc/90 Call Trace: ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout] nf_ct_set_timeout+0x7b/0x3c0 xt_ct_tg_check+0x724/0xb20 xt_check_target+0x234/0xa90 do_ipt_set_ctl+0x570/0x1270 Allocated by task 89: __kmalloc_noprof+0x16e/0x460 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 ops_undo_list+0x3d4/0x730 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout] Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74347", "url": "https://ubuntu.com/security/CVE-2026-74347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released. Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object. Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed. nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed. nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-97620", "url": "https://ubuntu.com/security/CVE-2026-97620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 (\"anv: don't prevent L1 untyped cache flush in 3D mode\"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97615", "url": "https://ubuntu.com/security/CVE-2026-97615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use option bits for CFM/MRP frame handlers CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another. These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case. Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97906", "url": "https://ubuntu.com/security/CVE-2026-97906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bootconfig: Fix integer overflow in initrd size check Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97619", "url": "https://ubuntu.com/security/CVE-2026-97619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: end write accounting from ->ki_complete Commit b000145e9907 moved both the fsnotify calls and the write accounting out of the kiocb completion handler and into the io_req_rw_complete() task_work. However, only the fsnotify part actually needed to move as it may sleep. Ending the write accounting is just a percpu_up_read() on the superblock writers sem. Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE protection depend on the ring owner getting to running task_work. But the task may be blocked in freeze_super(), causing it to never get to that: task io-wq worker -------------------------------------------------------------- io_write() io_kiocb_start_write() (takes sb_writers, hidden from lockdep by __sb_writers_release) write_iter() -> -EIOCBQUEUED ioctl(FS_IOC_SHUTDOWN) bdev_freeze() freeze_super() percpu_down_write() <- waits for the reader above io_write() kiocb_start_write() percpu_down_read() <- queued behind the writer io_complete_rw() queues io_req_rw_complete() <- never runs, task is in D state End the write from io_complete_rw() instead, and leave only the fsnotify calls in task_work.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97901", "url": "https://ubuntu.com/security/CVE-2026-97901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genetlink: pin family module during policy dump The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request. Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module. Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97918", "url": "https://ubuntu.com/security/CVE-2026-97918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Undo the registration when enabling the histogram trigger fails Commit 6f86bdeab633 (\"tracing: Fix bad hist from corrupting named_triggers list\") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: \tlist_add_tail_rcu(&data->list, &file->triggers); \tupdate_cond_flag(file); \tif (trace_event_trigger_enable_disable(file, 1) < 0) { \t\tlist_del_rcu(&data->list); \t\tupdate_cond_flag(file); \t\tret--; \t} so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind. Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well. Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97919", "url": "https://ubuntu.com/security/CVE-2026-97919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take the reference before publishing the named histogram trigger event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: \tdata->ref++; \tsave_named_trigger(data->named_data->name, data); \tret = event_hist_trigger_init(data->named_data); \tif (ret < 0) { \t\tkfree(data->cmd_ops); \t\tdata->cmd_ops = &trigger_hist_cmd; \t} \treturn ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way out. event_hist_trigger_parse() frees it, and the next lookup by name reads the freed object: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 67: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97933", "url": "https://ubuntu.com/security/CVE-2026-97933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening a tracer options file When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased. Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97935", "url": "https://ubuntu.com/security/CVE-2026-97935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: \tif (data->cmd_ops->init) { \t\tret = data->cmd_ops->init(data); \t\tif (ret < 0) \t\t\tgoto out; \t} \tif (hist_data->enable_timestamps) { \t\tret = tracing_set_clock(file->tr, hist_data->attrs->clock); \t\tif (ret) { \t\t\thist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); \t\t\tgoto out; \t\t} The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object: ~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 (\"tracing: Fix bad hist from corrupting named_triggers list\") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97949", "url": "https://ubuntu.com/security/CVE-2026-97949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: unhash the dentry before dropping the item in rmdir configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item. configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned. configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window: BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90 get_target fs/configfs/symlink.c:128 [inline] configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185 Unhash in configfs_remove_dir(), while the item is still guaranteed to be there. A reference obtained just before that stays harmless, as create_link() rechecks CONFIGFS_USET_DROPPING, already set by configfs_detach_prep(). Both configfs_unregister_subsystem() paths d_drop() after detaching, so this only makes rmdir match them.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97938", "url": "https://ubuntu.com/security/CVE-2026-97938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reboot: fix cad_pid use-after-free race cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid)", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97939", "url": "https://ubuntu.com/security/CVE-2026-97939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: account multicast table and route memory A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count. Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names. Unresolved MFC entries are still allocated from softIRQ with GFP_ATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 (\"ipmr: remove hard code cache_resolve_queue_len limit\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97934", "url": "https://ubuntu.com/security/CVE-2026-97934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from a \"STACKTRACE\" histogram key \"cpu\", \"CPU\", \"stacktrace\" and \"STACKTRACE\" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97950", "url": "https://ubuntu.com/security/CVE-2026-97950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: pin the symlink target's dirent instead of chasing ->ci_dentry create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target(). That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). Take the dirent in get_target() as well, under ->d_lock and atomically with the item reference, and pass it down to create_link(). A hashed dentry has not been killed yet, so its ->d_fsdata reference keeps the dirent alive there.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89806", "url": "https://ubuntu.com/security/CVE-2026-89806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93244", "url": "https://ubuntu.com/security/CVE-2026-93244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: simpledrm: Improve stride validation Validate the computed stride against the maximum value INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89827", "url": "https://ubuntu.com/security/CVE-2026-89827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97534", "url": "https://ubuntu.com/security/CVE-2026-97534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: accurately adjust free_sections during free_segment_range In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC. However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight. Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89832", "url": "https://ubuntu.com/security/CVE-2026-89832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty flag on folio in error path If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93285", "url": "https://ubuntu.com/security/CVE-2026-93285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: embed f2fs_gc_kthread in f2fs_sb_info Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store\t\t\t- remount|shutdown \t\t\t\t - f2fs_stop_gc_thread - access sbi->gc_thread \t\t\t\t - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-89837", "url": "https://ubuntu.com/security/CVE-2026-89837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dentry folio leak in find_in_level find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89838", "url": "https://ubuntu.com/security/CVE-2026-89838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: limit recovery filename logging to stored length F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.", "cve_priority": "negligible", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89840", "url": "https://ubuntu.com/security/CVE-2026-89840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate MOVE_RANGE destination size F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97529", "url": "https://ubuntu.com/security/CVE-2026-97529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] The FC BSG transport allocates job->request via memdup_user() using the exact user-supplied request_len. For FC_BSG_HST_VENDOR, fc_bsg_host_dispatch() only guarantees request_len covers msgcode and vendor_id; it does not account for the vendor_cmd[] flexible array. qla2xxx then reads the command selector vendor_cmd[0] and, in several sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor command area without verifying request_len. A caller holding CAP_SYS_RAWIO can submit a short request whose vendor_id matches the host, triggering out-of-bounds heap reads (KASAN-detectable, and able to mis-select a command or panic). Add a central guard in qla2x00_process_vendor_specific() so the selector is always in bounds, restrict the early vendor_cmd[0] read in qla24xx_bsg_request() to sufficiently long vendor messages, and add request_len checks to the sub-handlers that read further: qla24xx_proc_fcp_prio_cfg_cmd(), qla2x00_process_loopback(), qla84xx_reset(), qla84xx_updatefw(), qla2x00_read_optrom(), qla2x00_update_optrom(), qlafx00_mgmt_cmd() and qla28xx_validate_flash_image().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97527", "url": "https://ubuntu.com/security/CVE-2026-97527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock The fcport->unsol_ctx_head list is modified from several contexts without a common lock. Entries are added in qla2xxx_process_purls_iocb() from the response queue ISR (under the qpair qp_lock), while they are removed from qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp() (NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB completion). The qpair qp_lock cannot serialize this per-fcport list since multiqueue adapters add entries through different qpairs, so a concurrent add and delete (or two concurrent deletes) can corrupt the list pointers. Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del() on unsol_ctx_head. The add nests under the existing qp_lock; no delete path takes qp_lock, so the lock order is consistent and deadlock free.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97528", "url": "https://ubuntu.com/security/CVE-2026-97528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error qla_nvme_xmt_ls_rsp() obtains uctx, which was linked into fcport->unsol_ctx_head by qla2xxx_process_purls_iocb() and is still linked when the NVMe transport calls back to transmit the LS response. On the error (out:) path the function frees uctx with kfree() but never removes it from the list. This leaves a freed node in fcport->unsol_ctx_head: the next list_add_tail() for that fcport writes through the freed node, and a subsequent list_del() can corrupt the list or panic. Unlink uctx with list_del() before kfree() on the error path, matching the other free sites in qla_nvme_release_lsrsp_cmd_kref() and qla2xxx_process_purls_pkt(). qla2x00_rel_sp() in the failure path only returns the SRB to its pool and does not invoke sp->put_fn, so the out: path is the sole free and uctx is always still linked there.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97530", "url": "https://ubuntu.com/security/CVE-2026-97530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide whether the next continuation IOCB has arrived, spinning on cpu_relax() without advancing the ring or decrementing the entry count while it has not. response_t::signature lives at byte offset 60, but a continuation IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame payload at that offset (data[56..59]). A received frame whose payload bytes happen to equal 0xDEADDEAD is therefore misread as \"not yet arrived\", and the loop spins forever in interrupt/DPC context, causing a CPU soft lockup. The poll is also unnecessary: callers of qla27xx_copy_multiple_pkt() (PT_LS4_UNSOL and the NVMe purls path) already gate on qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are present before copying begins. The sibling helper __qla_copy_purex_to_buffer() already drops the signature poll and relies on the entry_type == STATUS_CONT_TYPE guard instead. Remove the signature busy-wait from both helpers, keeping the entry_type guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers and re-processes on the next interrupt once all continuation IOCBs have arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the signature field is never read on a continuation IOCB, eliminating the payload-aliasing lockup.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97531", "url": "https://ubuntu.com/security/CVE-2026-97531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip vport under deletion in report ID acquisition qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id. A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory. Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89868", "url": "https://ubuntu.com/security/CVE-2026-89868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add timeout while stop_streaming When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97535", "url": "https://ubuntu.com/security/CVE-2026-97535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array. max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout). Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97532", "url": "https://ubuntu.com/security/CVE-2026-97532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to probe_hw_failed and calls qla2x00_mem_free(). Several error labels in qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool, flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info) but left the pointers dangling. qla2x00_mem_free() then freed them a second time. Worse, for the dma_pool members it issued dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been destroyed and set to NULL at fail_s_dma_pool, dereferencing a NULL pool. Clear each freed pointer (and its DMA handle) in the error labels so the subsequent qla2x00_mem_free() skips them.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97536", "url": "https://ubuntu.com/security/CVE-2026-97536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair->qp_lock. During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha->wq) forces pending work to run after the queue pairs have been freed. Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97537", "url": "https://ubuntu.com/security/CVE-2026-97537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que(): 1. When dma_alloc_coherent() fails during queue creation, the error path calls the free function with req->ring / rsp->ring still NULL (from kzalloc). The unconditional dma_free_coherent() with a NULL cpu_addr is undefined behavior and can panic. 2. The free functions clear req_qid_map / rsp_qid_map under vport_lock, but the create functions protect the same bitmaps with mq_lock. This provides no mutual exclusion. Additionally, the create error path clears the bit and releases mq_lock before calling the free function, creating a window where another thread can allocate the same que_id and have its ha->req_q_map entry clobbered by the subsequent lockless NULL assignment in the free function. Fix by: - Guarding dma_free_coherent() with a NULL check on the ring pointer. - Using mq_lock (the lock held by all creators) in the free functions to atomically NULL the map entry and clear the bitmap bit. - Removing the now-redundant clear_bit blocks from the create error paths since the free functions handle it atomically.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89859", "url": "https://ubuntu.com/security/CVE-2026-89859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89921", "url": "https://ubuntu.com/security/CVE-2026-89921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-93196", "url": "https://ubuntu.com/security/CVE-2026-93196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: virtio_pmem: refcount requests for token lifetime KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-98161", "url": "https://ubuntu.com/security/CVE-2026-98161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: pmem: keep PREFLUSH before data writes pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier. Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.", "cve_priority": "low", "cve_public_date": "2026-09-25 14:17:00 UTC" }, { "cve": "CVE-2026-89956", "url": "https://ubuntu.com/security/CVE-2026-89956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89972", "url": "https://ubuntu.com/security/CVE-2026-89972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89996", "url": "https://ubuntu.com/security/CVE-2026-89996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious \"close it on the failure path\" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90002", "url": "https://ubuntu.com/security/CVE-2026-90002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Take trace_array reference before accessing its ftrace_ops The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90013", "url": "https://ubuntu.com/security/CVE-2026-90013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening options file The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90016", "url": "https://ubuntu.com/security/CVE-2026-90016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: \twhile (i < in_len) { \t\t... \t\tif (i + 5 < in_len && in_ie[i] == 0xDD && ...) { \t\t\t... \t\t\tbreak; \t\t} \t\ti += (in_ie[i + 1] + 2); /* to the next IE element */ \t} When the \"i + 5 < in_len\" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to \"i += (in_ie[i + 1] + 2)\", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f (\"staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie\") added the \"i + 5 < in_len\" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90023", "url": "https://ubuntu.com/security/CVE-2026-90023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90029", "url": "https://ubuntu.com/security/CVE-2026-90029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80935", "url": "https://ubuntu.com/security/CVE-2026-80935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy mt7996_mcu_get_eeprom() derives the destination of the EFUSE/EXT block copy from the address reported by the MCU response (event->addr, a device-controlled __le32) and clamps only the copy length, never the destination offset into dev->mt76.eeprom.data. A malicious or malfunctioning device can report an arbitrary address and drive an out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80939", "url": "https://ubuntu.com/security/CVE-2026-80939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot: SError Interrupt on CPU8, code 0x00000000be000011 -- SError Workqueue: events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211] cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] Kernel panic - not syncing: Asynchronous SError Interrupt On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64. Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs. This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-90030", "url": "https://ubuntu.com/security/CVE-2026-90030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: clear forceRM when issuing EndTransfer The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-93200", "url": "https://ubuntu.com/security/CVE-2026-93200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix use-after-free of master->this sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-80937", "url": "https://ubuntu.com/security/CVE-2026-80937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver's dev->mt76.eeprom.data buffer at the offset reported by the MCU response (res->addr, a device-controlled __le32) without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93199", "url": "https://ubuntu.com/security/CVE-2026-93199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Do not treat master device as a duplicate target i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-80980", "url": "https://ubuntu.com/security/CVE-2026-80980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: stop killed, freed and out_of_sync sharing a byte The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock(). Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89467", "url": "https://ubuntu.com/security/CVE-2026-89467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: qcom_battmgr: fix use-after-free qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service comes up, and the worker recovers battmgr through container_of() to issue firmware requests. The PMIC GLINK client stays on the client list until its devres release action runs, so a PDR notification can keep queueing the work, and a pending or running worker can access battmgr after devres frees it. Make enable_work device-managed with devm_work_autocancel(), registered before the PMIC GLINK client is allocated. The devres cleanup then releases the client first, so no further notification can queue the work, and cancels the work before battmgr is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81016", "url": "https://ubuntu.com/security/CVE-2026-81016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. \"SMU cmd failed. err: 0xff\") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89437", "url": "https://ubuntu.com/security/CVE-2026-89437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: int1092: Fix potential memory leak in sar_probe() The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89795", "url": "https://ubuntu.com/security/CVE-2026-89795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Allow per function PCI slots to fix slot reset on s390 On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 (\"s390/pci: Handling multifunctions\") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89441", "url": "https://ubuntu.com/security/CVE-2026-89441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: cancel card-detect work on remove Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89452", "url": "https://ubuntu.com/security/CVE-2026-89452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/msm: Unwind probe state on registration failure msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core. If iommu_device_sysfs_add() fails, probe returns with the object still on qcom_iommu_devices. The driver core then releases the devm allocation, leaving a dangling list entry that later list walks may dereference. If iommu_device_register() fails, the same dangling list entry remains and the sysfs device is left registered as well. Unwind the sysfs device and global list entry in reverse setup order on the corresponding failure paths.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89797", "url": "https://ubuntu.com/security/CVE-2026-89797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500_fg: fix use-after-free on remove ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93231", "url": "https://ubuntu.com/security/CVE-2026-93231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: fix swapped arguments in nlmsvc_match_ip() When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: \tnlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: \tmatch(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d (\"lockd: unlock lockd locks associated with a given server ip\"): \treturn rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: \treturn rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); [ cel: fix the misleading typedef parameter names too ]", "cve_priority": "low", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89500", "url": "https://ubuntu.com/security/CVE-2026-89500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page Discarding a cached reader page after a concurrent ring buffer resize uses the new global subbuf_order for the free_pages() call. This mismatched order may crashes the kernel or leaks memory because the cached page was allocated under the old size. Save the actual free_page order alongside the page address to ensure we always refer to the correct value and do not rely on the potentially stalled cpu_buffer->subbuf_order value. The simplest is to make free_page a buffer_data_read_page which already covers exactly what we need: a page address and a page order.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89520", "url": "https://ubuntu.com/security/CVE-2026-89520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Make core-sched flips wait for in-flight selections Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89503", "url": "https://ubuntu.com/security/CVE-2026-89503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set, it can allocate a reader page with an outdated order. This isn't a big issue, the user can still re-allocate a new reader page and try again. However, what is more problematic is if the value of subbuf_order changes in the middle of ring_buffer_alloc_read_page(). In that case, bpage->order might not match the actual allocated memory. Use bpage->order for the allocation to prevent this race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2025-37807", "url": "https://ubuntu.com/security/CVE-2025-37807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kmemleak warning for percpu hashmap Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.", "cve_priority": "negligible", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2026-72315", "url": "https://ubuntu.com/security/CVE-2026-72315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix busy dentry warning on unmount after DIO Commit c68337442f03 (\"cifs: Fix busy dentry used after unmounting\") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb() to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: \t[dio]\t\t\t[cifsd]\t\t\t[close + umount] netfs_unbuffered_write_iter_locked ... \t\t\t\tcifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] \t\t\t\t... \t\t\t\t netfs_write_subrequest_terminated \t\t\t\t netfs_subreq_clear_in_progress \t\t\t\t netfs_wake_collector // wake [1] \t\t\t\t netfs_put_subrequest netfs_put_request queue_work(system_dfl_wq, xxx) [2] // dio write return\t\t\t\t\tcifs_close \t\t\t\t\t\t\t _cifsFileInfo_put \t\t\t\t\t\t\t // cfile->count 2->1 \t\t\t\t\t\t\t --cfile->count [3] \t\t\t\t\t\t\t// umount \t\t\t\t\t\t\tcifs_kill_sb \t\t\t\t\t\t\t kill_anon_super \t\t\t\t\t\t\t // warning triggered! \t\t\t\t\t\t\t shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ... _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work(fileinfo_put_wq, xxx) [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput If the umount path is triggered before [5], it results warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] The existing per-inode ictx->io_count wait in cifs_evict_inode() does not help: it lives in the inode eviction path, which runs after shrink_dcache_for_umount() has already warned about the busy dentries. Fix it by adding a per-superblock outstanding-rreq counter that is incremented in cifs_init_request() and decremented in cifs_free_request(). In cifs_kill_sb(), before kill_anon_super(), wait for this counter to reach 0 - which guarantees that all cleanup_work for this sb have run and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Then drain the workqueue so the dentry refs are dropped. This is a targeted wait, not a flush of the system-wide system_dfl_wq.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89492", "url": "https://ubuntu.com/security/CVE-2026-89492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate directory-index entry counts when reading metadata ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks \tfor (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) \t\tdx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f (\"ocfs2: validate dx_root extent list fields during block read\") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93228", "url": "https://ubuntu.com/security/CVE-2026-93228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Reject Write/Reply chunks with segcount 0 A peer can send a Write or Reply chunk whose segcount field is zero. xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero passes the range check, and xdr_inline_decode(stream, 0) returns the current (non-NULL) cursor without advancing. The function returns true and pcl_alloc_write() then links a struct svc_rdma_chunk with ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl. An earlier patch in this series made pcl_for_each_segment() safe for ch_segcount == 0, so this no longer drives the memory walk it used to. Rejecting the malformed frame at the decode boundary is still worthwhile as defense in depth: it keeps degenerate zero-segment chunks off the parsed chunk lists entirely, so any future consumer that walks ch_segments directly cannot observe one, and it makes the zero-floor easy to backport to trees where the macro change is more intrusive. RFC 8166 has no meaning for a Write/Reply chunk that describes no remote buffer, so no legitimate client is affected. xdr_check_reply_chunk() funnels Reply chunks through xdr_check_write_chunk() and inherits the same rejection. pcl_alloc_write() also links each chunk onto the parsed chunk list before filling its segment array. If a future change weakens the segcount-0 rejection, an incomplete chunk is visible to consumers during the fill loop. Reorder so that list_add_tail() follows the segment fill loop, ensuring only fully-populated chunks appear on the list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89543", "url": "https://ubuntu.com/security/CVE-2026-89543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir Normal client creation goes through rpc_setup_pipedir(), which records clnt->pipefs_sb, but the mount-event path in __rpc_clnt_handle_event() calls rpc_setup_pipedir_sb() directly and never refreshes that field. The umount path also removes the directory without clearing clnt->pipefs_sb. After a late pipefs mount or any remount, rpc_clnt_remove_pipedir() compares the current superblock against a stale pipefs_sb pointer and skips cleanup, leaving pipefs dentries whose inode private data still points at a freed rpc_clnt, leading to a potential use-after-free during subsequent rpc_info_open() or rpc_show_info() calls. Fix this by properly updating clnt->pipefs_sb upon mount events and clearing it during unmount or failure paths.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89544", "url": "https://ubuntu.com/security/CVE-2026-89544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gssx_dec_option_array error path bugs Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose. gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gssp_accept_sec_context_upcall() gssx_dec_accept_sec_context() gssx_dec_option_array() /* fails, count=1 data=NULL */ data = res.options.data[0].value /* NULL deref */ Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation. The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory. Fix all four together: - Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array. - Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc. - In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89545", "url": "https://ubuntu.com/security/CVE-2026-89545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: defer rq_argp and rq_resp free until after RCU grace period svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu(). After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free. Fix this by moving the kfree of rq_argp and rq_resp into an explicit call_rcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain synchronously freed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89564", "url": "https://ubuntu.com/security/CVE-2026-89564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip: orphan prefetched skbs before multicast forwarding IPv4 and IPv6 input preserve an skb->sk association installed by bpf_sk_assign() so that local delivery can use the selected socket under RCU. Both address families can also prefetch a socket in UDP early demux. In both paths (BPF and UDP early demux) a reference is not guaranteed to be held on the socket. When a multicast packet is not locally deliverable, IPv6 hands the original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the original skb when local delivery is not needed. Either path can put the skb on an unresolved multicast route queue or forward it after the receive-side RCU section ends. After the prefetched socket is destroyed, a later skb free invokes sock_pfree() and dereferences the stale skb->sk. Orphan the skb before each non-local multicast forwarding path. Local delivery retains the original skb; the existing skb_clone() calls provide multicast forwarding with a socket-free clone.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89561", "url": "https://ubuntu.com/security/CVE-2026-89561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled. When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL. Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200: BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070 Read of size 4 at addr 00000000000006b4 by task ping6/394 CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full) Call Trace: kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup. Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89799", "url": "https://ubuntu.com/security/CVE-2026-89799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in bpf_get_stackid The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89572", "url": "https://ubuntu.com/security/CVE-2026-89572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix OPP table cleanup apple_soc_cpufreq_init() adds OPP tables from firmware, but some failure paths do not remove them. The driver also uses dev_pm_opp_remove_all_dynamic(), which is not the right cleanup helper for OPP tables loaded from firmware. Use the cpumask OPP helper after the policy CPU mask has been populated. Pair it with the matching cpumask remove helper on failure paths and in apple_soc_cpufreq_exit(). This also removes the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask helper loads the DT OPP tables for all CPUs in the policy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90037", "url": "https://ubuntu.com/security/CVE-2026-90037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.", "cve_priority": "critical", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90036", "url": "https://ubuntu.com/security/CVE-2026-90036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89622", "url": "https://ubuntu.com/security/CVE-2026-89622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in mcp->rxbuf for the duration of a transfer but never clears it when the transfer finishes or times out. Once the caller frees or reuses the buffer, mcp->rxbuf becomes a dangling pointer. A delayed or spurious MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to memcpy device data into the freed memory, causing a write use-after-free. Route all return paths through a single exit point that clears mcp->rxbuf and mcp->rxbuf_size, so that the existing !mcp->rxbuf guard in the raw_event handler can reject any report arriving after the transfer has ended.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90041", "url": "https://ubuntu.com/security/CVE-2026-90041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: clean up device list on probe failure sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89624", "url": "https://ubuntu.com/security/CVE-2026-89624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: universal-pidff: stop the device when force-feedback init fails universal_pidff_probe() starts the device with hid_hw_start() and then, if force-feedback initialisation fails, returns the error through a label that only does \"return error\". The device is left started. The HID core does not unwind on the driver's behalf. __hid_device_probe() releases the devres group, closes the report and clears hdev->driver: \tif (ret) { \t\tdevres_release_group(&hdev->dev, hdev->devres_group_id); \t\thid_close_report(hdev); \t\thdev->driver = NULL; \t} The hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added with cdev_device_add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid_device_remove() skips hid_hw_stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths. Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid_pidff_init_with_quirks() - no output reports, an allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, input_ff_create() - all reach the same label. Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do this. The two earlier gotos must keep returning without hid_hw_stop(), since neither has a started device, so give the path that fails after the start its own label. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89625", "url": "https://ubuntu.com/security/CVE-2026-89625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb(): \ttimer_delete_sync(&sc->ghl_poke_timer); \tusb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <- hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89644", "url": "https://ubuntu.com/security/CVE-2026-89644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map leak in NOCOW direct I/O write btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an extent map reference that must be dropped on all exit paths. For direct writes into a NOCOW range, btrfs_get_blocks_direct_write() keeps using that extent map and asks btrfs_create_dio_extent() to allocate the ordered extent. If that fails, for example because btrfs_alloc_ordered_extent() fails, the function returns the error without dropping the input extent map. The PREALLOC path avoided this by dropping the input extent map before replacing it with the newly created one. Check the error from btrfs_create_dio_extent() before replacing the map and drop the input extent map on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90042", "url": "https://ubuntu.com/security/CVE-2026-90042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new \"tname must never come from vmalloc()\" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89659", "url": "https://ubuntu.com/security/CVE-2026-89659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during delegation revoke A delegation stateid holds only a bare pointer to its owning nfs4_client and does not keep it alive. The client survives its stateids only because __destroy_client() drains cl_delegations and cl_revoked before free_client() runs. nfs4_laundromat() breaks that invariant: it unhashes an expired delegation from cl_delegations, drops deleg_lock, then revoke_delegation() relinks it onto cl_revoked under cl_lock. In that window the delegation is on neither list, so client_has_state() can report no remaining state. Every teardown path first requires cl_rpc_users to be zero, but the laundromat holds no such reference. A client whose recalled delegation has just timed out can therefore reach free_client() while revoke_delegation() is still about to dereference cl_lock, a use-after-free. Pin the client with cl_rpc_users across the revoke so teardown blocks until it completes, then reap the delegation from cl_revoked. A client already expiring reaps its own, so skip it and leave the delegation on del_recall_lru.", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89676", "url": "https://ubuntu.com/security/CVE-2026-89676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix stale s2s_cp_stateids IDR entry for async COPY For an async COPY, nfsd4_copy() called nfs4_init_copy_state() before dup_copy_fields(), so the s2s_cp_stateids IDR was pointed at &u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is reused by the next request. dup_copy_fields() copies only the value into async_copy, so the IDR slot dangled at the transient buffer for the whole background copy. Any IDR walker then dereferences reused request memory: the laundromat reads cs_type from it and, if the bytes look like an expired NFS4_COPYNOTIFY_STID, follows into refcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has the same exposure via idr_find(). Duplicate the fields first, then register the stateid on the stable async_copy. result->cb_stateid is unchanged.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89685", "url": "https://ubuntu.com/security/CVE-2026-89685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix clock domain mismatch in clients_still_reclaiming() clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline. This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients. Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89708", "url": "https://ubuntu.com/security/CVE-2026-89708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown After a DESTROY_SESSION the per-session teardown path can free a session while rpciod still holds an inflight callback rpc_task that dereferences clp->cl_cb_session. nfsd4_probe_callback_sync() flushes cl_callback_wq, but once nfsd4_run_cb_work() has called rpc_call_async() the rpc_task lives on rpciod; flushing the workqueue does not wait for it. rpc_shutdown_client() does drain rpciod tasks, but uses a 1-second wait_event_timeout — tasks stuck in rpc_delay() (e.g. 2-second NFS4ERR_DELAY retries) can outlive the drain. destroy path rpciod ------------ ------ unhash_session(ses) nfsd4_probe_callback_sync(clp) flush_workqueue(cl_callback_wq) /* returns; rpc_task still live */ nfsd4_put_session_locked(ses) free_session(ses) -> kfree(ses) nfsd4_cb_sequence_done() reads cb_clp->cl_cb_session /* freed slab */ A second window exists in nfsd4_process_cb_update(). When __nfsd4_find_backchannel() returns NULL because unhash_session() has already removed the destroyed session from cl_sessions, setup_callback_client() takes the v4.1 early return so clp->cl_cb_session = ses never fires and the field retains a pointer to the about-to-be-freed session. Fix both by converting cl_cb_session to an RCU-protected pointer: - Move the cl_cb_session = ses assignment in setup_callback_client() to after rpc_create() succeeds, so it is only published when a working backchannel exists. Clear cl_cb_session on the error return in nfsd4_process_cb_update(). Both stores use rcu_assign_pointer(). - Annotate cl_cb_session with __rcu. All rpciod-side readers use rcu_read_lock()/rcu_dereference() and check for NULL, bailing to the appropriate error or requeue path: encode_cb_sequence4args(), decode_cb_sequence4resok(), nfsd41_cb_get_slot(), nfsd41_cb_release_slot(), nfsd4_cb_prepare(), and nfsd4_cb_sequence_done(). - Switch __free_session() from kfree() to kfree_rcu() so the session slab is not reclaimed until after an RCU grace period, guaranteeing that rpciod readers inside rcu_read_lock() never dereference freed memory. - Pass the session pointer to the nfsd_cb_seq_status and nfsd_cb_free_slot tracepoints instead of having them re-read cl_cb_session. - nfsd4_cb_prepare() calls rpc_exit() when the session is NULL, routing through the done/release path to requeue the callback.", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89698", "url": "https://ubuntu.com/security/CVE-2026-89698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage struct nfsd_genl_rqstp declares rq_daddr and rq_saddr as plain \"struct sockaddr\" (16 bytes). When an IPv6 NFS client is connected, nfsd_genl_rpc_status_compose_msg() casts these fields to \"struct sockaddr_in6 *\" (28 bytes) and reads sin6_addr at offset 8..24, which extends 8 bytes past the end of the 16-byte sockaddr field into the adjacent rq_flags member. The 16-byte nla_put_in6_addr then ships 8 bytes of truncated IPv6 address followed by 8 bytes of rq_flags to userspace via the NFSD_A_RPC_STATUS_SADDR6/DADDR6 netlink attributes. This is reachable by any unprivileged process in the network namespace because NFSD_CMD_RPC_STATUS_GET uses GENL_CMD_CAP_DUMP without GENL_ADMIN_PERM. Fix by widening rq_daddr and rq_saddr to struct sockaddr_storage so the IPv6 casts operate within bounds, copying sizeof(struct sockaddr_storage) bytes in the memcpy calls so the full address is captured, and zero-initializing the genl_rqstp stack variable to prevent leaking uninitialized tail bytes through netlink.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2025-40210", "url": "https://ubuntu.com/security/CVE-2025-40210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"NFSD: Remove the cap on number of operations per NFSv4 COMPOUND\" I've found that pynfs COMP6 now leaves the connection or lease in a strange state, which causes CLOSE9 to hang indefinitely. I've dug into it a little, but I haven't been able to root-cause it yet. However, I bisected to commit 48aab1606fa8 (\"NFSD: Remove the cap on number of operations per NFSv4 COMPOUND\"). Tianshuo Han also reports a potential vulnerability when decoding an NFSv4 COMPOUND. An attacker can place an arbitrarily large op count in the COMPOUND header, which results in: [ 51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 when NFSD attempts to allocate the COMPOUND op array. Let's restore the operation-per-COMPOUND limit, but increased to 200 for now.", "cve_priority": "high", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2026-89693", "url": "https://ubuntu.com/security/CVE-2026-89693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create() nfsd4_create() stores the return value of nfsd4_acl_to_attr() in status, but the switch(create->cr_type) block unconditionally overwrites it in every branch. ACL translation errors are silently discarded, and the CREATE proceeds without the requested ACL. Add an early exit check after nfsd4_acl_to_attr(), matching the pattern already used in nfsd4_setattr(). [ cel: prefer NFS4ERR_BADTYPE over NFS4ERR_ATTRNOTSUPP ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89717", "url": "https://ubuntu.com/security/CVE-2026-89717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: set default primary compressor in zram_destroy_comps() Patch series \"zram: fix zram issues reported by sashiko\". Sashiko drove by and reported [1] a couple of zram issues: a possible BUG_ON() in zlib code due to missing winbits range validation and one possible NULL-ptr dereference in zcomp. Both are low risk yet still worth fixing. This patch (of 2): zram_destroy_comps() resets all compressors and leaves them set to NULL, including the primary one, which is invalid device state, as now comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set default primary compressor in zram_destroy_comps().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89718", "url": "https://ubuntu.com/security/CVE-2026-89718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in writeback_store() Patch series \"zram: fix stale scan bounds after reinitialization\". Both writeback_store() and read_block_state() derive their table scan bounds from zram->disksize before acquiring dev_lock. If the device is reset and reinitialized with a smaller disksize between that read and lock acquisition, the bound can describe the old table while the scan operates on the new one. This can lead to out-of-bounds slot accesses. Move both bound calculations under dev_lock so each bound remains consistent with the table throughout its scan. Keep the fixes separate because the affected interfaces originate from different commits and can be backported independently. This patch (of 2): writeback_store() calculates the table scan bounds before taking dev_lock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writeback_store() is waiting for the lock. Once it acquires the lock, it sees an initialized device but scans the new table using the old upper bound, resulting in an out-of-bounds access. Calculate the number of pages while holding dev_lock so the scan bound matches the table protected by the lock.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89719", "url": "https://ubuntu.com/security/CVE-2026-89719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in read_block_state() read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-90044", "url": "https://ubuntu.com/security/CVE-2026-90044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix Use-After-Free in AIO error path In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90045", "url": "https://ubuntu.com/security/CVE-2026-90045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: ffs: fix mm lifetime handling io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89731", "url": "https://ubuntu.com/security/CVE-2026-89731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read cxl_rch_get_aer_info() copies the RCH Downstream Port AER capability from the RCRB MMIO block using a readl() loop bounded by sizeof(struct aer_capability_regs). This struct is a software layout and its embedded struct pcie_tlp_log is larger than the on-wire AER capability. As a result the loop reads past the mapped AER register block. The over-read also populates the software-only tail fields including header_log.header_len. An out-of-range header_len passed to pcie_print_tlp_log() can then loop past the header log buffer and cause a second out-of-bounds read. The read was correct when introduced, but struct pcie_tlp_log has since grown (Header Log and TLP Prefix Log sizes, header_len and flit fields), so sizeof(struct aer_capability_regs) no longer matches the physical AER capability. Bound the read to the physical AER registers, header through the 16 byte Header Log. Zero the destination first so the software-only fields are deterministic.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89755", "url": "https://ubuntu.com/security/CVE-2026-89755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: clear stale mapping after freeing swapcache __migrate_device_pages() reads the folio mapping before calling folio_free_swap(). When folio_free_swap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swap_space. Passing the stale mapping to folio_migrate_mapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swap_space.i_pages with invalid reference accounting, eventually triggering a folio reference count BUG. After a successful split, nr still contains the number of pages in the original large folio, although each resulting page is now a separate order-0 folio. Reset nr to 1 so each split folio is processed separately, including its own swapcache removal and mapping lookup. Refresh the saved mapping after folio_free_swap() so the current folio state is used during migration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89763", "url": "https://ubuntu.com/security/CVE-2026-89763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM teardown ordering trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown. The current order permits this interleaving: CPU 0 CPU 1 trusted_tpm_exit() key_type_lookup(\"trusted\") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., digests) CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it. KASAN reported: BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510 Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-80945", "url": "https://ubuntu.com/security/CVE-2026-80945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - unmap dst before software fallback on decompress On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80847", "url": "https://ubuntu.com/security/CVE-2026-80847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clamp route advmss to TCP_MIN_MSS tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the \"default advmss\" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-97545", "url": "https://ubuntu.com/security/CVE-2026-97545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails LOLLM observes that in xfs_btree_bload_prep_block, xfs_btree_bload_drop_buf can hit an IO error if writing the delwri buffer list to disk fails. In this case, we fail to release new_bp, which means we lose a locked buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97552", "url": "https://ubuntu.com/security/CVE-2026-97552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: initialise error in xfs_defer_finish_one() xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the \"Done with the dfp, free it\" path, and the function returns an indeterminate value. An item-less pending item reaches this through xfs_defer_add_barrier(), which xfs_reap_ag_blocks() uses on any CONFIG_XFS_ONLINE_REPAIR kernel. xfs_defer_finish_noroll() treats any non-EAGAIN return as fatal, so a non-zero stack value turns a successful barrier into a SHUTDOWN_CORRUPT_INCORE in the middle of a repair. Zero is the correct result: reaching the free path means the item loop drained without a non-zero error.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97583", "url": "https://ubuntu.com/security/CVE-2026-97583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Clear stale peer app data after address list changes afs_fs_probe_fileserver() fetches the current endpoint state under server->fs_lock, but leaves old_alist as NULL. Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows. CPU 0 replaces server S's list and drops Pold without clearing Pold->app_data. The server destroyer then clears only S's current peers and lets S reach its RCU callback. After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold->app_data, and calls afs_use_server() on the freed object. KASAN reported: BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0 Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74 Call Trace: afs_find_server+0x3c/0xa0 afs_rx_new_call+0x15c/0x390 rxrpc_new_incoming_call+0x97c/0x1730 rxrpc_input_packet.constprop.0+0xd03/0xec0 rxrpc_io_thread+0x967/0x1640 Allocated by task 93: afs_lookup_server+0x1a7/0x14c0 afs_alloc_server_list+0x43f/0xb60 afs_create_volume+0x923/0x1490 afs_get_tree+0x1c6/0x10a0 Freed by task 0: kfree+0x131/0x3c0 rcu_core+0x50a/0x1850 Last potentially related work creation: __call_rcu_common.constprop.0+0x71/0xa10 afs_put_server+0x213/0x2b0 Preserve old->addresses for the peer app-data update so that removed peers are cleared before the endpoint state is replaced. Also advance both cursors when the old and new lists share a peer; activating the old/new comparison without this would otherwise loop forever on the shared entry.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97584", "url": "https://ubuntu.com/security/CVE-2026-97584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix incorrect free in candidate cleanup in afs_lookup_server() Fix afs_lookup_server() to not free an existing server's endpoint state when cleaning up a candidate server. The candidate record doesn't have an endpoint state yet at this point, so the free for that can just be removed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97587", "url": "https://ubuntu.com/security/CVE-2026-97587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: store available counter mask as bitmap The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97605", "url": "https://ubuntu.com/security/CVE-2026-97605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: preserve LZMA decoders on resize failure The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired. Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request. Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97606", "url": "https://ubuntu.com/security/CVE-2026-97606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: autofs: fix memory leak in autofs_fill_super() In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97616", "url": "https://ubuntu.com/security/CVE-2026-97616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: release all action references on NEWACTION failure When a batched RTM_NEWACTION request replaces an existing action, tcf_idr_check_alloc() takes a temporary reference on it. If a later action fails to initialize, tcf_action_destroy() uses strict release semantics to clean up the actions initialized so far. For an action bound to a filter, the strict check returns -EPERM without dropping the temporary reference. This error also makes tcf_action_destroy() return before releasing subsequent entries. Any new action initialized between the bound action and the failing entry is leaked together with its reserved IDR slot, preventing reuse of its index. Use tcf_idr_release() to drop each reference held by the batch without rejecting bound actions. This allows cleanup to continue through all initialized entries and preserves the module reference release when an action is destroyed. Explicit action deletion and flushing retain their separate bind-count checks.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97902", "url": "https://ubuntu.com/security/CVE-2026-97902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: don't return -EINVAL for successful nested thaw Commit 7366f8b6fc6a (\"fs: handle freezing from multiple devices\") replaced the freeze_holders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw that released a shared hold while another holder remained returned 0. Since the rework, thaw_super_locked() drops the freeze reference via freeze_dec() but then returns -EINVAL when other freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the remaining holders. This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and additionally frozen via bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'s return value, so nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted again: dm-1: Can't mount, blockdev is frozen There is no way for userspace to drop the leaked count; only destroying the block device (or a reboot) recovers the device. Reproducer (any kernel since v6.8): dmsetup create dut --table \"0 $(blockdev --getsz \"$DEV\") linear $DEV 0\" mkfs.ext4 /dev/mapper/dut mount /dev/mapper/dut /mnt fsfreeze --freeze /mnt # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() # keeps bd_fsfreeze_count at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount /dev/mapper/dut /mnt # EBUSY, forever The same happens with fsfreeze held across an LVM snapshot of the origin volume. fs_bdev_thaw()'s documentation already describes the intended semantics: \"If this function returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times\". Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without holding a freeze still fails with -EINVAL as may_unfreeze() rejects that case before the reference count is touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97908", "url": "https://ubuntu.com/security/CVE-2026-97908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running. Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97915", "url": "https://ubuntu.com/security/CVE-2026-97915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Limit firmware log name prints to field size The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97916", "url": "https://ubuntu.com/security/CVE-2026-97916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate firmware log buffer metadata The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc instead of re-reading them from the shared struct.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97917", "url": "https://ubuntu.com/security/CVE-2026-97917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr Add a size parameter to ivpu_to_cpu_addr() and validate that the whole [vpu_addr, vpu_addr + size) range stays within the BO.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97929", "url": "https://ubuntu.com/security/CVE-2026-97929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: validate URB actual_length in interrupt callback i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length. A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array. Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97953", "url": "https://ubuntu.com/security/CVE-2026-97953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TX descriptor availability check for TSO traffic stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: \t(skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97961", "url": "https://ubuntu.com/security/CVE-2026-97961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Allow list_del during perf_event_overflow() A PMU might use perf_sched_cb_inc() and perf_sched_cb_dec() interface to get the PMU call back function pmu::sched_task invoked at schedule in and schedule out. This is achieved by walking along the list anchored by sched_cb_list. The following scenario might lead to a list corruption. perf_pmu_sched_task() for_each_list_entry(..., &sched_cb_list) +--> __perf_pmu_sched_task() +--> event->pmu->sched_task()) +--> PMU_push_sample() +--> perf_event_overflow() +--> __perf_event_overflow() +--> pmu->stop() +--> perf_sched_cb_dec() remove entry from sched_cb_list while list node in use. This happens when ioctl(fd, PERF_EVENT_IOC_REFRESH, xxx) has been invoked and perf_event::event_limit hits zero. Prevent the list corruption and convert for_each_list_entry() to for_each_list_entry_safe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97965", "url": "https://ubuntu.com/security/CVE-2026-97965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: initialize _md in vxlan_xmit_one() If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable: if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) { if (info->options_len < sizeof(*md)) goto drop; md = ip_tunnel_info_opts(info); } Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr(): if (vxflags & VXLAN_F_GBP) vxlan_build_gbp_hdr(vxh, md); Inside vxlan_build_gbp_hdr(), md->gbp is read: if (!md->gbp) return; gbp = (struct vxlanhdr_gbp *)vxh; ... if (md->gbp & VXLAN_GBP_DONT_LEARN) gbp->dont_learn = 1; If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire. Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97978", "url": "https://ubuntu.com/security/CVE-2026-97978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: ice: don't dereference pointers from TP_printk() After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 (\"tracing: Warn when an event dereferences a pointer in TP_printk()\"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97985", "url": "https://ubuntu.com/security/CVE-2026-97985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Update last skb marker in manage_oob(). Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK): socketpair(AF_UNIX, SOCK_STREAM, 0, sk); 1) skb -> OOB skb -> NULL send(sk[0], \"ab\", 2, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 2) skb -> consumed OOB skb -> NULL send(sk[0], \"ab\", 2, MSG_OOB); recv(sk[1], buf, 1, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 3) consumed OOB skb -> OOB skb -> NULL send(sk[0], \"a\", 1, MSG_OOB); recv(sk[1], buf, 0, MSG_OOB); send(sk[0], \"b\", 1, MSG_OOB); recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let's update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97992", "url": "https://ubuntu.com/security/CVE-2026-97992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: protect config_ctx from being freed under the config callback vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock: \tstruct eventfd_ctx *config_ctx = v->config_ctx; \tif (config_ctx) \t\teventfd_signal(config_ctx); VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context: \tswap(ctx, v->config_ctx); \tif (ctx) \t\teventfd_ctx_put(ctx); eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory. The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context. This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 (\"vhost-vdpa: fix use-after-free of v->config_ctx\"), which was about vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer is maintained correctly and it is the read side that is unprotected. With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for. A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds: BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vduse_dev_irq_inject Call Trace: native_queued_spin_lock_slowpath+0x97/0x5b0 _raw_spin_lock_irqsave+0xd4/0xe0 eventfd_signal_mask+0x69/0x120 vhost_vdpa_config_cb+0x34/0x50 vduse_dev_irq_inject+0x46/0x60 process_one_work+0x468/0x950 Allocated by task 2992: do_eventfd+0x50/0x200 __x64_sys_eventfd2+0x2e/0x40 Freed by task 2992: eventfd_ctx_put+0xb9/0xc0 vhost_vdpa_unlocked_ioctl+0x116c/0x2190 Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value. Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98018", "url": "https://ubuntu.com/security/CVE-2026-98018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: i3c: serialize probe with bus removal mctp_i3c_probe() drops busdevs_lock after finding the matching bus. A concurrent I3C_NOTIFY_BUS_REMOVE can then unregister and free the bus netdev before probe passes its private data to mctp_i3c_add_device(). The latter consequently adds a list node through a freed mbus pointer. Keep busdevs_lock held until the device has been added. This also satisfies the __must_hold annotation on mctp_i3c_add_device().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98021", "url": "https://ubuntu.com/security/CVE-2026-98021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: reject oversized tx_queue_len at netlink parse time rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with \"ip link add ... txqueuelen 500000\" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks. Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper \"integer out of range\" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it). Document the bound in the rt-link.yaml netlink spec. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn): ip link add v0 txqueuelen 500000 type veth peer name v1 -> on the fixed kernel this is rejected with -ERANGE (\"integer out of range\" extack) instead of installing an oversized tx_queue_len that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98028", "url": "https://ubuntu.com/security/CVE-2026-98028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: nfp: drop the replaced rule from the list when reprogramming fails nfp_net_fs_add() replaces an existing rule by deleting it from the hardware, decrementing nn->fs.count and programming the new one. If nfp_net_fs_add_hw() fails the old entry stays on nn->fs.list - only the success path reaches list_replace() - so the list is one longer than nn->fs.count, and it advertises a rule whose hardware entry has already been torn down. nn->fs.count is what ETHTOOL_GRXCLSRLCNT reports, so userspace then sizes its buffer one entry short of what the GRXCLSRLALL walk wants to write. That used to overwrite one u32 past the allocation; since the walk is bounded it is a permanent -EMSGSIZE instead, as nothing ever resyncs the counter.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98029", "url": "https://ubuntu.com/security/CVE-2026-98029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: nfp: bound the ntuple rule dump by the caller's buffer size nfp_net_get_fs_loc() dumps every entry of nn->fs.list into rule_locs[] without consulting cmd->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed flow steering rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Bail out with -EMSGSIZE when the buffer fills up, the way the other ntuple capable drivers do, and report how many locations were filled so a shrinking rule list does not leave the caller reading stale slots.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98037", "url": "https://ubuntu.com/security/CVE-2026-98037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject untrusted allocated-object pointers When the final RCU read-side critical section ends, a local kptr is demoted to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer to an object whose lifetime is no longer protected. type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with MEM_ALLOC as a live allocated object. In particular, a refcount-only local kptr never carries NON_OWN_REF, so it still passes the bpf_refcount_acquire() argument check after RCU protection ends. The kfunc can then dereference NULL or stale memory. Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since type_is_non_owning_ref() is based on the same predicate, graph kfunc arguments obey the same live-object requirement. Fault-protected reads of the demoted pointer remain valid: writes are already rejected, and read fixups use bpf_may_fault_on_deref() rather than this predicate. [ kkd: Rewrote commit log ]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98039", "url": "https://ubuntu.com/security/CVE-2026-98039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Require MEM_PERCPU for percpu kptr stores map_kptr_match_type() treats perm_flags as the set of register type flags that a kptr field permits. Adding MEM_PERCPU to that set for BPF_KPTR_PERCPU does not require the source register to carry it, however. The subset test consequently accepts both a plain bpf_obj_new() allocation and a referenced kernel pointer into a __percpu_kptr map field. Loads from the field are always marked MEM_PERCPU. Consumers then treat the stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer helpers relocate it, and map teardown selects the per-CPU free path. A plain allocation can therefore provide an arbitrary kernel read/write, while a kernel pointer can be relocated into an invalid address or sent through a missing destructor. Require the source MEM_PERCPU flag to match the destination field kind. This preserves valid bpf_percpu_obj_new() stores and rejects both the program-BTF and kernel-BTF variants.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98041", "url": "https://ubuntu.com/security/CVE-2026-98041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98054", "url": "https://ubuntu.com/security/CVE-2026-98054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix unbalanced module reference count strace_open() invokes try_module_get() which on success takes the module reference. If any follow up operation causes strace_open() to fail, the refcount shall be put down.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98056", "url": "https://ubuntu.com/security/CVE-2026-98056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: remove stale namespaces by NSID range during scan nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98081", "url": "https://ubuntu.com/security/CVE-2026-98081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: finish active block group cleanup if call_zone_finish() fails do_zone_finish() clears BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE before finishing the zones. If call_zone_finish() then fails it returned early, leaving the now inactive block group on fs_info->zone_active_bgs, leaking its reference, the BTRFS_FS_NEED_ZONE_FINISH waiters are never woken, and as its alloc_offset equals the zone capacity btrfs_zone_finish_one_bg() keeps selecting it, spinning btrfs_zoned_activate_one_bg(). Fall through to the cleanup on failure too and return the error, but keep the block group read-only as its zones are left inconsistent.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98097", "url": "https://ubuntu.com/security/CVE-2026-98097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Dont send random pad bytes in RESET/ACTIVATE messages The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer. Replace the strcpy(data, l->if_name) with memcpy() so that the pad bytes are actually written (l->if_name[] is zero padded) rather than sending random bytes from the skb to the remote system. Replace two other strcpy() with strscpy().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98103", "url": "https://ubuntu.com/security/CVE-2026-98103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igmp: convert struct ip_sf_list to RCU Commit 23d2b94043ca (\"igmp: Add ip_mc_list lock in ip_check_mc_rcu\") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions. However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()). When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock. Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c: 1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE(). Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98107", "url": "https://ubuntu.com/security/CVE-2026-98107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs. However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent. Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded. Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see. Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98114", "url": "https://ubuntu.com/security/CVE-2026-98114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: propagate DACL parsing errors parse_dacl() silently accepts truncated ACEs and allocation failures, allowing set_info_sec() to continue with an incomplete ACL conversion. Return parsing and allocation errors to parse_sec_desc() so malformed security descriptors are rejected before inode attributes or ACL xattrs are updated.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98126", "url": "https://ubuntu.com/security/CVE-2026-98126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for zero range When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing the file to grow beyond the caller's file-size limit. Fix this by calling inode_newsize_ok() before sending the zero-range request when the operation would extend EOF. Reproducer, using a file on a CIFS mount: \tbash -c ' \t FILE=/mnt/cifs/repro \t trap \"\" SIGXFSZ \t ulimit -f 3072 \t truncate -s 2M \"$FILE\" \t fallocate --zero-range -o 0 -l 4M \"$FILE\" \t echo \"fallocate rc=$?\" \t stat -c \"file size=%s\" \"$FILE\" \t' Before this change, the operation succeeds despite the 3 MiB limit: \tfallocate rc=0 \tfile size=4194304 After this change, fallocate fails and leaves the file at 2 MiB.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98127", "url": "https://ubuntu.com/security/CVE-2026-98127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: \tbash -c ' \t\tFILE=/mnt/cifs/repro \t\ttrap \"\" SIGXFSZ \t\tulimit -f 3072\t\t# RLIMIT_FSIZE = 3 MiB \t\t# A regular write is stopped at 3 MiB. \t\tdd if=/dev/zero of=\"$FILE\" bs=1M count=4 status=none \t\tstat -c \"size after write: %s\" \"$FILE\" \t\t# Insert 2 MiB into a 2 MiB file. \t\ttruncate -s 2M \"$FILE\" \t\tfallocate -i -o 0 -l 2M \"$FILE\" \t\tstat -c \"size after insert: %s\" \"$FILE\" \t' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: \tdd: error writing '/mnt/cifs/repro': File too large \tsize after write: 3145728 \tsize after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: \tdd: error writing '/mnt/cifs/repro': File too large \tsize after write: 3145728 \tfallocate: fallocate failed: File too large \tsize after insert: 2097152", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98151", "url": "https://ubuntu.com/security/CVE-2026-98151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: \tr0 = bpf_map_lookup_elem(...)\t/* PTR_TO_MAP_VALUE, offset 0 */ \t... \t14: r0 += r1\t\t\t/* r1 is a bounded scalar */ \t15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): \tverifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out \tof sync with range bounds r64={.base=0x0, .size=0x0} \tr32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74735", "url": "https://ubuntu.com/security/CVE-2026-74735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: fix tunnel and session refcount leak on seq_file release In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-72438", "url": "https://ubuntu.com/security/CVE-2026-72438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending and barrier reference leaks on discard failures raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-93793", "url": "https://ubuntu.com/security/CVE-2026-93793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: validate TX_CMD response layout TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload. For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93796", "url": "https://ubuntu.com/security/CVE-2026-93796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: null RX pointers after free When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free(). The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93801", "url": "https://ubuntu.com/security/CVE-2026-93801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: zero-initialize stack-allocated cifs_open_info_data Stack-allocated cifs_open_info_data may contain random data. This can make some fields have wrong value if they are not set later.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93804", "url": "https://ubuntu.com/security/CVE-2026-93804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: ibss: wait for in-flight TX on disconnect While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues. Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93817", "url": "https://ubuntu.com/security/CVE-2026-93817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix addr_filter_ranges lifetime Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93828", "url": "https://ubuntu.com/security/CVE-2026-93828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix handling of damaged volume in exfat_create_upcase_table() When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely. If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97412", "url": "https://ubuntu.com/security/CVE-2026-97412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: quiesce DMA before freeing resources pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97428", "url": "https://ubuntu.com/security/CVE-2026-97428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: harden FRU PIA parsing with bounded helpers Replace the open-coded TLV walk with fru_pia_advance() and fru_pia_copy_field() helpers that bound every read by the actual EEPROM data length, preventing out-of-bounds reads on truncated or malformed FRU data.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97473", "url": "https://ubuntu.com/security/CVE-2026-97473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() When topology_physical_package_id()/topology_logical_die_id() returns a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL) directly without freeing the rapl_package structure that was just allocated by kzalloc_obj(), leaking memory on every failed package addition. Use the existing err_free_package label so that the allocation is released on the error path.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97494", "url": "https://ubuntu.com/security/CVE-2026-97494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer. Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97505", "url": "https://ubuntu.com/security/CVE-2026-97505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check. Resizing a BAR modifies PCI device configuration and can disrupt active drivers. After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups(). Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97514", "url": "https://ubuntu.com/security/CVE-2026-97514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Fix Reports from Kernel Lock Validator handle_dynamic_resolution change requires that the state_lock be acquired based on the lockdep_assert_held. However, the handle_dynamic_resolution_change call in initialize_sequence does not properly obtain the lock before calling. Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called while a lock is already held. Store off the fbc_buf_count then properly update control once lock has been freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97518", "url": "https://ubuntu.com/security/CVE-2026-97518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject duplicate wiphy cipher suite entries Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them. One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE. Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97520", "url": "https://ubuntu.com/security/CVE-2026-97520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: move quota_init qc iterator increment Move qc++ from the loop body into the for-loop increment expression in gfs2_quota_init(). This keeps iterator progression explicit and avoids mixing pointer advance with duplicate-slot handling in the loop body.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-80836", "url": "https://ubuntu.com/security/CVE-2026-80836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - bound the akcipher result length virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80925", "url": "https://ubuntu.com/security/CVE-2026-80925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 (\"ipvlan: inherit needed_headroom and needed_tailroom from phy_dev\") cef51860becd (\"macvlan: inherit needed_headroom and needed_tailroom from lowerdev\")", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80841", "url": "https://ubuntu.com/security/CVE-2026-80841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: defer vmalloc TX_RING free until skbs finish AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80861", "url": "https://ubuntu.com/security/CVE-2026-80861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: bail out of setup if the controller is inaccessible xhci_gen_setup() locates the operational registers using the capability length read from the very first register: \txhci->op_regs = hcd->regs + \t\tHC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up (\"Unable to change power state from D3cold to D0, device inaccessible\") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2025-40097", "url": "https://ubuntu.com/security/CVE-2025-40097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix missing pointer check in hda_component_manager_init function The __component_match_add function may assign the 'matchptr' pointer the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced. The call stack leading to the error looks like this: hda_component_manager_init |-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign |-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereference Add IS_ERR() check to prevent the crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "low", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-98102", "url": "https://ubuntu.com/security/CVE-2026-98102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src() When removing a source filter whose count reaches zero, ip6_mc_del1_src() unlinks psf from pmc->mca_sources. If the filter was previously active, the code moved psf directly into pmc->mca_tomb by updating psf->sf_next. Because pmc->mca_sources is traversed locklessly under RCU (e.g. by ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mca_sources and improperly examine deleted tombstone entries. Fix this by allocating a new tombstone node for pmc->mca_tomb (as done in sf_setstate()) and retiring the original psf via kfree_rcu().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98101", "url": "https://ubuntu.com/security/CVE-2026-98101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source() pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths. ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array. Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries. Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter(). Also remove the now unused IP6_SFBLOCK macro.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97522", "url": "https://ubuntu.com/security/CVE-2026-97522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix bad accounting in __mptcp_subflow_push_pending() If __subflow_push_pending() errors out we should avoid updating the copied byte counters, to avoid mismatch push call later on.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97540", "url": "https://ubuntu.com/security/CVE-2026-97540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. Instead of keeping a side table for additional information, use driver_info field of the usb_device_id. The dynamic ID parsing code needs to be updated for this; convert it to just write to the reserved entry for dynamic ID and remove the weird loop.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97541", "url": "https://ubuntu.com/security/CVE-2026-97541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: don't store usb_device_id usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from usb_device, so just store driver_data.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97539", "url": "https://ubuntu.com/security/CVE-2026-97539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xusbatm: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. xusbatm initialize the USB device IDs dynamically so it can just use driver_info too. Even with conversion, xusbatm still cannot support dynamic IDs, so also set no_dynamic_id.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97542", "url": "https://ubuntu.com/security/CVE-2026-97542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bail out on bitmap errors in xrep_agfl_fill LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill can fail, but we don't check the result of xagb_bitmap_walk, so we silently drop the error and proceed with inconsistent incore data. That shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97555", "url": "https://ubuntu.com/security/CVE-2026-97555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix heap overflow in DACL owner/group rewrite When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smb_ace)). If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation. Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which covers the smb_acl header and room for every ACE at maximum SID size. This replaces the previous split logic that used dacl_ptr->size for cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid mounts: both paths can trigger the same rewrite and need the same headroom. KASAN reports this as: BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs] Write of size 4 at addr ffff8881a5e25374 by task chown/5298 ... The buggy address is located 0 bytes to the right of allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97556", "url": "https://ubuntu.com/security/CVE-2026-97556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid leaking refcount when cifs_sb_tlink() fails cifs_oplock_break() takes over the reference that cifs_queue_oplock_break() acquired when it queued the work, and drops it with _cifsFileInfo_put() once the break has been processed. Only in setups with \"-o multiuser\", cifs_sb_tlink() may fail, at which point cifs_oplock_break() returns without putting the file reference, mirroring the reference leak we already fixed in the companion patch to cifs_queue_oplock_break(). This would trigger a crash due to busy inodes on the next unmount: BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) Drop the reference on that path as well. Doing so before the out label mirrors the normal path, which also puts the reference before cifs_done_oplock_break(). Found by Sashiko code review. The failure path was not exercised at runtime.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97557", "url": "https://ubuntu.com/security/CVE-2026-97557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid leaking refcount in cifs_queue_oplock_break() cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97560", "url": "https://ubuntu.com/security/CVE-2026-97560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix one-byte OOB read in smb2_parse_native_symlink() When parsing a share-root relative native symlink, memcpy copies smb_target+1 (skipping the leading separator) but uses strlen(smb_target)+1 as the length, reading one byte past the allocated buffer. This fixes the following KASAN splat when accessing an SMB symlink with a target of '\\a\\b': BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0 Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1 CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N 7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996) Call Trace: dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 smb2_parse_native_symlink+0x4f5/0xca0 parse_reparse_point+0x68a/0x1530 reparse_info_to_fattr+0x752/0xa20 cifs_get_fattr+0x873/0x15b0 cifs_get_inode_info+0xc0/0x310 cifs_lookup+0x308/0xa70 __lookup_slow+0x122/0x2b0 lookup_slow+0x50/0x70 path_lookupat+0x525/0xaf0 filename_lookup+0x1f2/0x550 vfs_statx+0xd1/0x1a0 vfs_fstatat+0x65/0xc0 __do_sys_newfstatat+0x9a/0x120 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97562", "url": "https://ubuntu.com/security/CVE-2026-97562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: pin DFS superblock in iterator callback tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it. A deterministic KASAN test reproduces the race as: BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80 The same test passes with this change applied. Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97564", "url": "https://ubuntu.com/security/CVE-2026-97564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.idmap descriptions cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in \"os:\"/\"gs:\"/\"oi:\"/\"gi:\" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc (\"smb: client: reject userspace cifs.spnego descriptions\"), which applied the same restriction to cifs.spnego.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97575", "url": "https://ubuntu.com/security/CVE-2026-97575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate AV1 tile counts The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97577", "url": "https://ubuntu.com/security/CVE-2026-97577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info buffer, and programs the real tile_cols / tile_rows into the hardware. The tile group entry control is a dynamic array sized to the number of entries userspace submitted, independent of tile_cols / tile_rows, so a frame that claims more tiles than entries reads past the array. A frame that claims more than AV1_MAX_TILES tiles also leaves the hardware programmed for more tiles than the descriptor buffer holds. Reject both in prepare_run(): tile_cols * tile_rows must not exceed the submitted entry count or AV1_MAX_TILES. The entry count is read via v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1 decoder already enforces.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97578", "url": "https://ubuntu.com/security/CVE-2026-97578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer rockchip_vpu981_av1_dec_set_tile_info() divides context_update_tile_id by tile_info->tile_cols and writes one descriptor per tile into the tile_info DMA buffer, which holds AV1_MAX_TILES entries; tile_cols and tile_rows come from the bitstream. Guard the division against a zero tile_cols by initialising the context-update values to zero and computing them only when tile_cols is non-zero, and stop the descriptor writes once the tile_info buffer is full. The tile geometry written to the hardware registers is left unmodified; the per-dimension and total tile bounds are enforced by the control validation.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97579", "url": "https://ubuntu.com/security/CVE-2026-97579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity vdec_av1_slice_setup_tile() copies tile_cols + 1 / tile_rows + 1 entries into mi_col_starts[] / mi_row_starts[] from the bitstream tile_info. Bound the copy to the array capacity.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97581", "url": "https://ubuntu.com/security/CVE-2026-97581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity prepare_tile_info_buffer() writes one entry per tile into the tile_sizes DMA buffer, sized for a grid equal to the PPS uAPI array capacity. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers so the loops stay inside the buffer.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97595", "url": "https://ubuntu.com/security/CVE-2026-97595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual \"waiting for %s to become free\"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97599", "url": "https://ubuntu.com/security/CVE-2026-97599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: \tpib_old = rtnl_dereference(phy->pib); \t... \trcu_assign_pointer(phy->pib, pib); \tkfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97602", "url": "https://ubuntu.com/security/CVE-2026-97602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: invalidate queues before flushing them fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() use the old nhoffset with a new skb and access memory out of bounds. The resulting heap corruption can be leveraged for local privilege escalation when unprivileged network namespaces are available. Unflushed fragments can also keep conntrack references alive after the conntrack per-net cleanup point. Kill each incomplete queue, then flush every queue still owned by the dying rhashtable. HASH_DEAD identifies that ownership, while complete queues without it are already owned by another destroy path and must be left alone. Releasing a timer reference removed by inet_frag_kill() is deferred to inet_frag_putn(), after the queue lock is dropped. KASAN report: BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97607", "url": "https://ubuntu.com/security/CVE-2026-97607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Put device on unsupported feature error Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97613", "url": "https://ubuntu.com/security/CVE-2026-97613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Reserve extra CQ slot for the fence completion CQE The RX completion queue is sized to hold exactly one CQE per posted RX WQE. MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after the packet CQEs. The current sizing reserves no extra slot for it and in rare cases, CQ has no guaranteed slot for the fence CQE when it is full of packet CQEs. This can lead to dropping the fence completion while the driver waits holding RTNL lock throughout the timeout duration. Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory() requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE; the reservation pushes cq_size past a power-of-two, so round up the CQ size in mana_create_rxq().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97900", "url": "https://ubuntu.com/security/CVE-2026-97900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/drm_exec: fix up contended obj when num_objects is 0 drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97907", "url": "https://ubuntu.com/security/CVE-2026-97907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally ignores all security headers. However, the implementation simply breaks from a switch statement and leaks uninitialized return code `rc' (if the first section is a security one) or the previous section's `rc'. Fix it by really skipping a loop with `continue'. For consistency and readability, also do the same for the default case.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97920", "url": "https://ubuntu.com/security/CVE-2026-97920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Keep the entry count when the histogram stats allocation fails print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: \tn_entries = tracing_map_sort_entries(map, ...); \tif (n_entries < 0) \t\treturn n_entries; \t... \t\t\tif (!stats) { \t\t\t\tn_entries = -ENOMEM; \t\t\t\tgoto out; \t\t\t} \t... out: \ttracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with \"tracing: hist: let values keep the percent and graph modifiers\", so it should be applied first.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97921", "url": "https://ubuntu.com/security/CVE-2026-97921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: \thist_field = parse_expr(hist_data, file, field_str, flags, var_name, \t\t\t\t&n_subexprs); \t... \tif (hist_field->flags & HIST_FIELD_FL_VAR) { \t\tif (hist_field->flags & (...)) \t\t\tgoto err; \t} else { \t\tif (hist_field->flags & (...)) \t\t\tgoto err; \t} \thist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e (\"tracing: Do not let histogram values have some modifiers\") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \\ \t events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97922", "url": "https://ubuntu.com/security/CVE-2026-97922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram var refs regardless of how often they are referenced Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f (\"tracing: Fix histogram code when expression has same var as value\") then made repeated references share one object and added a count of them. Only the increment side exists, since those expressions still return early and never drop a reference, so __destroy_hist_field() sees how many references were created rather than how many are left. It frees when the decremented count is 0 or 1, so two references work and three or more leak. Sharing kept one array entry per object, and create_var_ref() searches and appends within a single trigger, so nothing outside it holds the object. Removing a trigger whose variables are still referenced is already refused by check_var_refs() with -EBUSY. Drop the count and free unconditionally.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97924", "url": "https://ubuntu.com/security/CVE-2026-97924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Don't destroy fields when event removal fails destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the event when the removal fails so the event remains in a consistent state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97925", "url": "https://ubuntu.com/security/CVE-2026-97925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA\t\t\t\t\tCPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; \t\t\t\t\ttick_install_broadcast_device(dev) \t\t\t\tclockevents_exchange_device(cur, dev) \t\t\t\t\t shutdown(cur); \t\t\t\t\t detach(cur); \t\t\t\t\t cur->handler = noop; \t\t\t\t\t tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97936", "url": "https://ubuntu.com/security/CVE-2026-97936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the \".stacktrace\" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: \tn_entries = *stack; \tmemcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, \"must be a long[] type\", so enforce it once the name has been resolved. Names which resolve to no field at all, \"hitcount.stacktrace\" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97945", "url": "https://ubuntu.com/security/CVE-2026-97945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix user-space data loss with MADV_FREE and THP Some of users of Polars (a data analytics library) have lost production data from this bug. They seem to have just the right combination of huge pages, MADV_FREE and heavy reclaim pressure. pmd_modify() masks the old value with (_HPAGE_CHG_MASK & ~_PAGE_DIRTY), silently discarding the hardware dirty bit. The subsequent pmd_mksaveddirty() call is supposed to transfer _PAGE_DIRTY into _PAGE_SAVED_DIRTY when write-protecting, but the dirty bit was already stripped from the value, so there is nothing left to transfer. Contrast with pte_modify(), which keeps _PAGE_DIRTY_BITS in its mask, and pud_modify(), which keeps _HPAGE_CHG_MASK untouched: pmd_modify() is the odd one out. Any pmd_modify() on a writable, dirty PMD loses the dirty state. One visible consequence is data loss with MADV_FREE on PMD-mapped THP: memset(buf, 0x5A, size); // PMD-mapped THP, PMD dirty madvise(buf, size, MADV_FREE); // PMD cleaned but left writable, // folio marked lazyfree memset(buf, 0x5A, size); // hardware sets _PAGE_DIRTY again mprotect(buf, size, PROT_READ); // pmd_modify() drops the dirty bit mprotect(buf, size, PROT_READ|PROT_WRITE); // ... memory pressure ... Reclaim (e.g. under memcg pressure) then finds the lazyfree folio with no dirty bit set anywhere and frees it in __discard_anon_folio_pmd_locked(), even though the data was rewritten after MADV_FREE; subsequent reads fault in fresh zero pages. NUMA hinting alone can trigger the same loss, as do_huge_pmd_numa_page() restores the PMD through pmd_modify() as well. PMD-mapped file THPs are affected too: mprotect()/NUMA hinting dropping the dirty bit means rewritten data is never written back. Fix it by keeping _PAGE_DIRTY in the preserved mask, exactly like pte_modify() and pud_modify() do. The existing pmd_mksaveddirty()/pmd_clear_saveddirty() pair then performs the hardware-dirty <-> saved-dirty transition based on the write bit, preserving the shadow-stack encoding rules.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97966", "url": "https://ubuntu.com/security/CVE-2026-97966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: reset HTB scheduler topology before freeing queues HTB offload programs NIX_AF_TLxX_TOPOLOGY on QoS-allocated scheduler queues via otx2_qos_txschq_set_parent_topology(), but teardown freed those queues without clearing TOPOLOGY. The AF only restores PARENT and SCHEDULE on free, so PRIO_ANCHOR/RR_PRIO settings can survive in the shared scheduler pool and affect later allocations. Add otx2_qos_reset_schq_topology() and otx2_qos_free_hw_schq() to zero TL4 through TL2 TOPOLOGY before each schq is returned to the AF during hierarchy teardown and cfg rollback. Skip the aggregation level (TL1): it is a per-tx-link queue shared by the PF, default Tx hierarchy and VFs, and is not freed back to the AF by nix_txschq_free_one().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97973", "url": "https://ubuntu.com/security/CVE-2026-97973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: destroy the phylink instance on the probe error path macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97977", "url": "https://ubuntu.com/security/CVE-2026-97977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Fix UAF of btusb_data by rx_work btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns. btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data: \twhile ((skb = skb_dequeue(&data->acl_q))) \t\tdata->recv_acl(data->hdev, skb); Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97979", "url": "https://ubuntu.com/security/CVE-2026-97979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: add missing xa_destroy for sched_node_ids Commit 16dfa49406bc (\"ice: Introduce new parameters in ice_sched_node\") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97984", "url": "https://ubuntu.com/security/CVE-2026-97984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce (included in the new selftest): 1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of IPv6 header). Device MTU allows it (it's only one byte bigger than IP6_MAX_MTU, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only. The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc (\"net: ipv6: introduce ip6_dst_mtu_maybe_forward\"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 (\"[INET]: Add IP(V6)_PMTUDISC_RPOBE\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97986", "url": "https://ubuntu.com/security/CVE-2026-97986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_input: stop callbacks before unregistering input device virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97987", "url": "https://ubuntu.com/security/CVE-2026-97987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_input: reset device if input_register_device() fails Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97990", "url": "https://ubuntu.com/security/CVE-2026-97990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_net: check TX pull result before RX copy vringh_iov_pull_iotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb(). A negative error can therefore become a large length in the RX path. Handle non-positive pull results before every length use. Count the TX error and complete the consumed TX descriptor with zero bytes. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97994", "url": "https://ubuntu.com/security/CVE-2026-97994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98007", "url": "https://ubuntu.com/security/CVE-2026-98007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject non-scalar bpf_loop iteration counts bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 (\"bpf: keep track of max number of bpf_loop callback iterations\"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the \"backtracking misuse\" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98008", "url": "https://ubuntu.com/security/CVE-2026-98008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix NULL pointer dereference on unbind with fixed-link When the device tree describes a fixed-link and has no \"mdio\" child node, macb_mii_init() returns early without allocating the MDIO bus, leaving bp->mii_bus as NULL. Two cleanup paths then dereference this NULL bus: 1. On driver unbind, macb_remove() unconditionally calls mdiobus_unregister(bp->mii_bus), which oopses: Unable to handle kernel NULL pointer dereference at virtual address 00000000000004a8 pc : mdiobus_unregister+0x14/0xa4 lr : macb_remove+0x38/0xa4 Call trace: mdiobus_unregister+0x14/0xa4 (P) macb_remove+0x38/0xa4 platform_remove+0x20/0x30 device_release_driver_internal+0x1c8/0x224 unbind_store+0xb4/0xbc 2. On the probe error path in macb_probe(), reached when macb_mii_init() has succeeded but a subsequent step fails, the err_out_unregister_mdio label runs the same unconditional cleanup. mdiobus_unregister() and mdiobus_free() do not guard against a NULL bus, so guard the calls in both macb_remove() and the probe error path.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98017", "url": "https://ubuntu.com/security/CVE-2026-98017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: defer qdisc freeing after failed creation An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98020", "url": "https://ubuntu.com/security/CVE-2026-98020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix cmd_regs access racing BAR unmap on reset pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path clear/iounmap cmd_regs without devcmd_lock, and pdsc_legacy_firmware_update()'s download loop derefs cmd_regs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmd_regs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO. Take devcmd_lock across the BAR unmap/remap, and re-check cmd_regs in the download loop. Only the PF maps cmd_regs and runs devcmd, so skip the unmap on a VF, as pdsc_remove() and pdsc_reset_done() already do. A reset that completes entirely within the unlocked window is not a correctness problem for the image: the device clears its update session, so a resumed download is rejected, and it verifies the staged image before writing a flash slot, reporting PDS_RC_BAD_FW rather than activating it. pdsc_unmap_bars() also clears info_regs, intr_status and intr_ctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdsc_fw_down(), which frees the interrupts and tears down the queues. The debugfs readers are not, since those files outlive a reset; that is pre-existing and out of scope here.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98024", "url": "https://ubuntu.com/security/CVE-2026-98024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: folio_put() after error dmb->cpu_addr was allocated via folio_alloc(). Use folio_put() instead of kfree() in the error exit of ism_alloc_dmb() to avoid slab allocator corruption. While at it, reset dmb->cpu_addr after folio_put to avoid unintentional UAF by future callers.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98026", "url": "https://ubuntu.com/security/CVE-2026-98026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: properly convert mglist to rcu Sashiko reported a bug [1] that br_multicast_del_port_group unlists the port group not using proper rcu helper that preserves the next pointer and after that immediately frees the port group without waiting for rcu grace period. The only rcu walker of mglist is br_multicast_list_adjacent() and it turns out that function has always been buggy because mglist was never properly converted to RCU. Fix it by converting it to rcu and moving its initialization after eth_addr's. Initializing p->next can use RCU_INIT_POINTER because we have a barrier from the hlist_add_head_rcu call later, besides we're initializing an unpublished structure anyway. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826014200.362304-1-littleddfu%40gmail.com", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98046", "url": "https://ubuntu.com/security/CVE-2026-98046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf_btf_find_by_name_kind() as sleepable When bpf_btf_find_by_name_kind() finds a type in module BTF, it returns a new BTF object fd through __btf_new_fd(). This reaches anon_inode_getfd(), which can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks. The fd allocation can then sleep in softirq context and install the fd into the interrupted task. Mark the helper as sleepable. This preserves calls from the main body of a sleepable syscall program while rejecting calls from its non-sleepable regions.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98051", "url": "https://ubuntu.com/security/CVE-2026-98051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times The loop initialised next_index from intf->tx_spb_index on every iteration, so incr_ring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances next_index and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98052", "url": "https://ubuntu.com/security/CVE-2026-98052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: clear txcb->last before writing each descriptor bcmasp_xmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when tx_spb_ring_full() underreported fullness), bcmasp_tx_reclaim() would see last == true mid-SKB and call dev_consume_skb_any() prematurely, freeing the sk_buff while its remaining fragments were still in flight. Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98055", "url": "https://ubuntu.com/security/CVE-2026-98055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Clean up the bus when fetching ML caps fails snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98082", "url": "https://ubuntu.com/security/CVE-2026-98082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix the possible bioc_list memory leak during error There are two possible ways to leak bioc memory on btrfs_ordered_extent::bioc_list: - An error occurred for btrfs_insert_one_raid_extent() Then the function btrfs_insert_raid_extent() immediately return without freeing any bioc in the bioc_list. - An ordered extent hit an IO error In that case the ordered extent will have BTRFS_ORDERED_IOERR set, and skip the call on btrfs_insert_raid_extent() completely. Fix the problem by: - Introduce a new helper, btrfs_cleanup_ordered_bioc_list() Which will remove all bioc from the bioc_list, and release the bioc. - Call the above helper for btrfs_insert_raid_extent() So that the cleanup helper is always called no matter what. - Call the above helper for btrfs_finish_one_ordered() This is called just before the final release on the ordered extent. This was reported by Sashiko when reviewing another patch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98083", "url": "https://ubuntu.com/security/CVE-2026-98083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix transaction use-after-free in raid stripe insertion If allocation of a RAID stripe extent fails, btrfs_insert_one_raid_extent() aborts and ends the transaction before returning -ENOMEM. btrfs_finish_one_ordered(), the production caller through btrfs_insert_raid_extent(), still owns the transaction handle. It handles the error by aborting the transaction and then reaches the common exit path, which ends the transaction again. The premature end can free the handle and drop its transaction reference. Transaction cleanup can then free the transaction before the caller's second abort accesses the handle and transaction, resulting in use-after-free. Keep the abort at the failure site, but let the caller's common exit path end the transaction once, after it has finished using both objects.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98086", "url": "https://ubuntu.com/security/CVE-2026-98086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: do not touch legacy_rmidi before it exists snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as \"legacy_rmidi is live\" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98089", "url": "https://ubuntu.com/security/CVE-2026-98089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix uninitialized transport header access in alb_determine_nd() alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98092", "url": "https://ubuntu.com/security/CVE-2026-98092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98104", "url": "https://ubuntu.com/security/CVE-2026-98104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) — ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98109", "url": "https://ubuntu.com/security/CVE-2026-98109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix race condition during device registration In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98111", "url": "https://ubuntu.com/security/CVE-2026-98111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: validate version TLV value lengths btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98122", "url": "https://ubuntu.com/security/CVE-2026-98122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every MDBE_ATTR_SRC_LIST member, accepts the all-zeros address. A source list is only accepted on a (*, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (*, G) key and resolves to the same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is then left with a zero address family. vxlan_mdb_remote_src_del() removes the forwarding entry of a source before freeing the source entry: \tvxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr); \tvxlan_mdb_remote_src_entry_del(ent); With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlist_del() reads ->pprev and ->next out of it and writes through them. Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlan_mdb_remote_srcs_replace(). BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 __vxlan_mdb_add+0x1cd/0xd70 vxlan_mdb_add+0xc0/0x140 rtnl_mdb_add+0x157/0x2a0 rtnetlink_rcv_msg+0x207/0x5a0 Allocated by task 84: __kmalloc_cache_noprof+0x153/0x360 vxlan_mdb_remote_srcs_add+0x2eb/0x440 __vxlan_mdb_add+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlan_mdb_remote_del+0x129/0x1a0 __vxlan_mdb_del+0x4f/0xe0 vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0 __vxlan_mdb_add+0x1c5/0xd70 The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers both call sites. A (*, G) entry is expressed by omitting the source, so nothing legitimate is refused. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98128", "url": "https://ubuntu.com/security/CVE-2026-98128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() mpi3mr_get_tgtdev_by_addr() increments the target device kref when it returns a device. If a subsequent error triggers a goto out_fail after the tgtdev reference is acquired, the reference is never released because the out_fail path does not call mpi3mr_tgtdev_put(). This prevents the target device structure from ever being freed. Add a tgtdev put in the out_fail path, guarded by a NULL check since tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98129", "url": "https://ubuntu.com/security/CVE-2026-98129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() sas_port_alloc_num() can return NULL on memory allocation failure. The return value is passed directly to sas_port_add() without a NULL check, which causes a NULL pointer dereference. Additionally, if sas_port_add() fails, the allocated port is not freed before jumping to out_fail, leaking the sas_port structure. Call sas_port_free() to properly release it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98142", "url": "https://ubuntu.com/security/CVE-2026-98142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/cirrus-qemu: Validate BAR0 size during probe The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`. If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created. When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault: BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline] drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312 Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98155", "url": "https://ubuntu.com/security/CVE-2026-98155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Address potential out-of-bounds read in resp_worker() Although 'commit 2feec5ae5df7 (\"accel/qaic: Handle DBC deactivation if the owner went away\")' fixes the scenario it was intended for by walking the message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it skipped over the bounds checking code that is included in decode_message(). This could lead to issues such as reading past the slab allocation's end, infinite loops or kernel panics. For those issues to happen, a malformed wire message is needed to be sent from the device. Instead of duplicating the bounds checking code already present in decode_message(), use the function inside resp_worker().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-80521", "url": "https://ubuntu.com/security/CVE-2026-80521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74521", "url": "https://ubuntu.com/security/CVE-2026-74521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use memcmp() to compare ClientGUIDs ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74294", "url": "https://ubuntu.com/security/CVE-2026-74294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: aiu: Validate written enum values The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74291", "url": "https://ubuntu.com/security/CVE-2026-74291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74289", "url": "https://ubuntu.com/security/CVE-2026-74289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't dump dying fib_info in fib_leaf_notify(). syzbot reported use-after-free in nsim_fib4_prepare_event(). [0] The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe. * mlxsw_sp_router_fib4_event() * rocker_router_fib_event() * nsim_fib4_prepare_event() refcount_inc_not_zero() must be used, but it would be too late there. Let's guarantee the lifetime of fib_info in fib_leaf_notify(). Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock. [0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74258", "url": "https://ubuntu.com/security/CVE-2026-74258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard __get_user acesss with access_ok for uprobe_multi data As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it. [1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72485", "url": "https://ubuntu.com/security/CVE-2026-72485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: platform: defer connection counter increment until alloc succeeds coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72413", "url": "https://ubuntu.com/security/CVE-2026-72413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix err_chunk memory leaks in INIT handling When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths: 1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it. 2. In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path. 3. In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it. Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init().", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72402", "url": "https://ubuntu.com/security/CVE-2026-72402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Mask pseudo pointer values in verifier logs print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72334", "url": "https://ubuntu.com/security/CVE-2026-72334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix malformed ISO_END/CONT handling Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. If controller sends too short ISO_END we accept it. Fix by marking unfinished ISO_START via conn->rx_skb != NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98159", "url": "https://ubuntu.com/security/CVE-2026-98159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: validate CLC firmware records The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93781", "url": "https://ubuntu.com/security/CVE-2026-93781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Do not block on tag allocation in scsi_eh_lock_door() scsi_eh_lock_door() is called from scsi_restart_operations() while the host is still in the SHOST_RECOVERY state, i.e. before the host is switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the queues. It allocates a request via scsi_alloc_request() with no flags, so blk_mq_get_tag() may block waiting for a free sched tag when all tags are already in use. Those tags can be held by commands that were just requeued by scsi_eh_flush_done_q() during error handling. Such commands cannot be dispatched until the host leaves SHOST_RECOVERY and scsi_run_host_queues() is called - which only happens *after* scsi_eh_lock_door() returns. This forms a circular dependency: - scsi_eh_lock_door(), running in the SCSI error handler thread, waits for a sched tag held by a requeued command; - the requeued command cannot complete and release its sched tag until the error handler thread leaves scsi_restart_operations() and restart the queues. For devices with a single driver tag (e.g. USB storage) it is a guaranteed deadlock and I/O that can never be submitted. This problem has also been reproduced in our environment. Locking the door is a best-effort operation, and scsi_eh_lock_door() already returns silently when the request allocation fails. Pass BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails instead of blocking when no tag is available. This breaks the circular dependency and allows the error handler to finish restarting the queues, after which the pending commands are dispatched normally.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93786", "url": "https://ubuntu.com/security/CVE-2026-93786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: preserve VFS inherited POSIX ACL mask The VFS initializes a child's POSIX ACL from the parent's default ACL and the requested creation mode. Do not mutate the parent ACL or overwrite the child's VFS-computed access and default ACLs afterwards. This preserves restrictive ACL_MASK entries and prevents SMB object creation from widening effective permissions.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93787", "url": "https://ubuntu.com/security/CVE-2026-93787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: bound dirent name against end of SMB response in cifs_filldir cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93788", "url": "https://ubuntu.com/security/CVE-2026-93788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: acpi: validate WGDS table revision index Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when firmware reports an invalid revision value.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93790", "url": "https://ubuntu.com/security/CVE-2026-93790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93791", "url": "https://ubuntu.com/security/CVE-2026-93791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: add a check on the tid coming from the firmware ba_notif->tid is a firmware-controlled u8 that is used directly as an array index into tid_data[] without any validation. Add a bounds check against IWL_MAX_TID_COUNT before dereferencing the array.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93792", "url": "https://ubuntu.com/security/CVE-2026-93792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix a possible underflow We shouldn't trust the firmware about the length of the wowlan packet.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93794", "url": "https://ubuntu.com/security/CVE-2026-93794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: flush dirty data before punching a hole Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with: xfs_io -f \\ -c \"pwrite -b 3m -S 0x61 0 3m\" \\ -c \"fpunch 1m 1m\" \\ -c \"seek -h 0\" \\ -c \"seek -d 1m\" \\ /mnt/test/repro Punching 1 MiB at offset 1 MiB should produce: 0 1 MiB 2 MiB 3 MiB | DATA | HOLE | DATA | EOF Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M. This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole. Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA. The xfstests generic/539 pass against Samba/ksmbd with this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93799", "url": "https://ubuntu.com/security/CVE-2026-93799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: validate sta_id in BA window status notif BA_WINDOW_STATUS_NOTIFICATION_ID extracts a 5-bit sta_id from the firmware notification and uses it to index fw_id_to_mac_id[] without bounds checking. Validate sta_id before array access to prevent out-of-bounds indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93806", "url": "https://ubuntu.com/security/CVE-2026-93806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate assoc response length before status and IE access cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run. Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93809", "url": "https://ubuntu.com/security/CVE-2026-93809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: flush pending RCU callbacks on module unload Call rcu_barrier() in module exit to wait for outstanding call_rcu() callbacks before freeing module text, preventing late callback execution in freed memory. BUG: unable to handle page fault for address: ffffffffc1d59c40 PGD 6a12067 P4D 6a12067 PUD 6a14067 PMD 13698b067 PTE 0 Oops: 0010 [#1] SMP NOPTI RIP: 0010:0xffffffffc1d59c40 Code: Unable to access opcode bytes at RIP 0xffffffffc1d59c16. RSP: 0018:ffffc900198c0f28 EFLAGS: 00010286 RAX: ffffffffc1d59c40 RBX: ffff897c7d6b61c0 RCX: ffff88826aff4590 RDX: ffff8884d8b35490 RSI: ffffc900198c0f30 RDI: ffff88812af67290 RBP: 000000000000000a (DONE segment entries) R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: ffffffff82a06100 R12: ffff88811a4e3700 R13: 0000000000000000 R14: ffff897c7d6b6270 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff897c7d680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc1d59c16 CR3: 00000104a980a001 CR4: 0000000002770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? rcu_do_batch+0x163/0x450 ? rcu_core+0x177/0x1c0 ? __do_softirq+0xc1/0x280 ? asm_call_irq_on_stack+0xf/0x20 ? do_softirq_own_stack+0x37/0x50 ? irq_exit_rcu+0xc4/0x100 ? sysvec_apic_timer_interrupt+0x36/0x80 ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? cpuidle_enter_state+0xd4/0x360 ? cpuidle_enter+0x29/0x40 ? cpuidle_idle_call+0x108/0x1a0 ? do_idle+0x77/0xf0 ? cpu_startup_entry+0x19/0x20 ? secondary_startup_64_no_verify+0xbf/0xcb (cherry picked from commit feaa5039f6c12acc9aa934c2d45dcd251a12c69f)", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93810", "url": "https://ubuntu.com/security/CVE-2026-93810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix double fput Fix a double fput() in error handling in cachefiles_create_tmpfile().", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93814", "url": "https://ubuntu.com/security/CVE-2026-93814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: core: Abort active target transfer on controller suspend When an SPI controller operating in target mode has a transfer in progress at the time of system suspend, the suspend path proceeds without aborting the ongoing transfer. This can leave the hardware in an inconsistent state, potentially causing the system to hang or fail to resume cleanly. Fix this by invoking the controller's target_abort callback from spi_controller_suspend() when the controller is in target mode and the callback is registered. This ensures any active target transfer is cleanly terminated before the controller is suspended.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93823", "url": "https://ubuntu.com/security/CVE-2026-93823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl amdkfd driver needs allocate buffer to return bo metadata to user space. The buffer size is controlled by user currently. It is a potential security issue that hostile value (e.g. 2 GiB) lets any render-group user trigger order-MAX allocation/OOM in kernel context. This patch first finds bo metadata size. If the size is smaller than user provided value drive can safely allocate buffer in kernel space and copy to user space buffer. If not, driver will let user know, not allocate and copy. User will redo with new buffer in user space. This patch lets driver decide buffer allocation size to avoid potential hostile size from user space. (cherry picked from commit f54ce9e8cbd3abe0eda3a285f54dc4f572fe589a)", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93824", "url": "https://ubuntu.com/security/CVE-2026-93824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: reject the combination of TLS and sockmap TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable. We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock). This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93826", "url": "https://ubuntu.com/security/CVE-2026-93826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hidpp: fix potential UAF in hidpp_connect_event() If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93829", "url": "https://ubuntu.com/security/CVE-2026-93829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix races in cifsd thread creation The cifsd demultiplex thread can run and access tcp_ses before the parent thread has finished populating tcp_ses, which the worker thread accesses locklessly. Also, the kthread_run macro may start the thread before returning the thread pointer. Because the pointer is part of the structure that the thread can access, if the kernel is preempted after the thread is spawned, but before the thread pointer is populated and the thread attempts to exit, it will sleep, waiting for a SIGKILL signal. Fix this by moving creation of the thread to after all of tcp_ses'es fields are populated, and spawning the thread last, using a split kthread_create/wake_up_process logic.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97409", "url": "https://ubuntu.com/security/CVE-2026-97409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Do not cancel requests in io target before it is initialized A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl(). nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace: dump_stack_lvl+0x57/0x80 register_lock_class+0x567/0x580 __lock_acquire+0x330/0xb90 lock_acquire.part.0+0xad/0x210 blk_mq_tagset_busy_iter+0xf9/0xc00 __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc] nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc] process_one_work+0x82c/0x1450 worker_thread+0x5ee/0xfd0 kthread+0x3a0/0x750 ret_from_fork+0x439/0x670 ret_from_fork_asm+0x1a/0x30 Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97415", "url": "https://ubuntu.com/security/CVE-2026-97415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF ROOT_REF and ROOT_BACKREF items contain a struct btrfs_root_ref followed by the subvolume name. Several readers assume that this layout is already valid and then use the on-disk name length directly. A corrupted item can therefore make those readers address bytes outside the item, and BTRFS_IOC_GET_SUBVOL_INFO can copy too many bytes into its fixed-size UAPI name buffer. Validate ROOT_REF and ROOT_BACKREF items in tree-checker before any reader uses them. Reject records that do not contain a non-empty name, whose name_len does not exactly describe the remaining item payload, or whose name exceeds BTRFS_NAME_LEN. For BTRFS_IOC_GET_SUBVOL_INFO, copy only the validated on-disk name_len instead of deriving the copy length from the item size. The ioctl result is zeroed when allocated. That leaves the existing trailing zero byte untouched.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97425", "url": "https://ubuntu.com/security/CVE-2026-97425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix buffer overflow during vBIOS update Clamp the buffer postion to write by setting the bin attribute to the maximum buffer size so that VFS layer will block the out-of-bounds accessing.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97427", "url": "https://ubuntu.com/security/CVE-2026-97427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: bound pp_dpm_set_pp_table() memcpy The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97429", "url": "https://ubuntu.com/security/CVE-2026-97429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix UAF race in destroy_queue_cpsch wait_on_destroy_queue() drops locks to wait for queue resume, allowing a concurrent destroy to free the queue. Use is_being_destroyed flag to serialize destruction.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97442", "url": "https://ubuntu.com/security/CVE-2026-97442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97447", "url": "https://ubuntu.com/security/CVE-2026-97447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97495", "url": "https://ubuntu.com/security/CVE-2026-97495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on allocate_doorbell allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97496", "url": "https://ubuntu.com/security/CVE-2026-97496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix OOB memory exposure in get_wave_state() The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97497", "url": "https://ubuntu.com/security/CVE-2026-97497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97500", "url": "https://ubuntu.com/security/CVE-2026-97500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: phy: check length before parsing PHY status IE Hardware might report PHY status IE with unexpected length, and parser might access out of range. Check the length ahead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97509", "url": "https://ubuntu.com/security/CVE-2026-97509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Keep XDomain reference during the lifetime of a service This is needed because we release the service ID in tb_service_release() and the ID array is owned by the parent XDomain.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97512", "url": "https://ubuntu.com/security/CVE-2026-97512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM The runtime PM functions had incomplete error handling that could leave the system in an inconsistent state. If any operation failed midway through suspend or resume, some resources would be left in the wrong state while others were already changed, leading to potential clock/power imbalances. Reorder the suspend/resume sequences to avoid brownout risk by ensuring the performance state is set appropriately before clocks are enabled and clocks are disabled before dropping the performance state. Fix by adding proper error checking for all operations and using goto-based cleanup to ensure all successfully acquired resources are properly released on any error.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97516", "url": "https://ubuntu.com/security/CVE-2026-97516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result() It was recently reported that rtw_fw_adaptivity_result() in fw.c dereferences rtwdev->chip->edcca_th without a NULL check. The issue is that devices with the 8821CE chip don't define edcca_th in their chip info. As a result, when rtw_fw_adaptivity_result() tries to dereference it, the kernel triggers an oops. Add a NULL check for edcca_th before dereferencing it in rtw_fw_adaptivity_result() in fw.c. Placing the check at the function entry avoids logging any garbage values. This change does not address the root cause for this behavior, but it prevents the NULL dereference and the resulting oops while a more permanent solution is developed. Tested on a 8822CE chip which defines edcca_th, so this issue is not present on it, but it still uses this driver and I can verify there are no regressions.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97517", "url": "https://ubuntu.com/security/CVE-2026-97517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject beacons with bad HE operation The HE operation element not only needs to be longer than the fixed part, but also have an appropriate size for the variable part inside of it. Check this.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90057", "url": "https://ubuntu.com/security/CVE-2026-90057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90060", "url": "https://ubuntu.com/security/CVE-2026-90060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90066", "url": "https://ubuntu.com/security/CVE-2026-90066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) 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 (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: 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:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90076", "url": "https://ubuntu.com/security/CVE-2026-90076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) 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": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90090", "url": "https://ubuntu.com/security/CVE-2026-90090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: \terr = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, \t\t\t round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which \"Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX\" ensures.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90091", "url": "https://ubuntu.com/security/CVE-2026-90091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90092", "url": "https://ubuntu.com/security/CVE-2026-90092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90101", "url": "https://ubuntu.com/security/CVE-2026-90101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix call to hardware monitoring event handler The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90108", "url": "https://ubuntu.com/security/CVE-2026-90108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: \tif (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { \t\tlgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; \t\tsmc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); \t\t... \t} A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90109", "url": "https://ubuntu.com/security/CVE-2026-90109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90110", "url": "https://ubuntu.com/security/CVE-2026-90110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inetpeer: randomize RB-tree node comparison using SipHash The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90112", "url": "https://ubuntu.com/security/CVE-2026-90112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlcnic: validate unified ROM sections before loading The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90115", "url": "https://ubuntu.com/security/CVE-2026-90115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix NULL pointer dereference in __xsk_rcv() In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90119", "url": "https://ubuntu.com/security/CVE-2026-90119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90122", "url": "https://ubuntu.com/security/CVE-2026-90122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: visconti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90124", "url": "https://ubuntu.com/security/CVE-2026-90124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-rzg2l: Fix loss of interrupt rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90125", "url": "https://ubuntu.com/security/CVE-2026-90125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: \trc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, \t\t\t\t (void **) &req, total_len); \tif (rc) \t\treturn rc; \tif (server == NULL) \t\treturn -ECONNABORTED; \t[...] \t\trdata->mr = smbd_register_mr(server->smbd_conn, \t\t\t\t\t &rdata->subreq.io_iter, \t\t\t\t\t true, need_invalidate); \t\tif (!rdata->mr) \t\t\treturn -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: \twdata->mr = smbd_register_mr(...); \tif (!wdata->mr) { \t\trc = -EAGAIN; \t\tgoto async_writev_out; \t} Commit b7972092199f (\"cifs: smbd: Retry on memory registration failure\") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90130", "url": "https://ubuntu.com/security/CVE-2026-90130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: fix cleanup after worker creation failure vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90135", "url": "https://ubuntu.com/security/CVE-2026-90135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 (\"net: add net device refcount tracker infrastructure\") added ref_tracker_dir_exit() to only free_netdev() path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90137", "url": "https://ubuntu.com/security/CVE-2026-90137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix password encoding bounds check The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90138", "url": "https://ubuntu.com/security/CVE-2026-90138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: don't check the listener's sk_err in vsock_accept() Syzbot reported an issue which can be reproduced with these steps: \tr0 = socket(AF_VSOCK, SOCK_STREAM, 0) \tbind(r0, {VMADDR_CID_ANY, PORT}) \tconnect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) \tlisten(r0, backlog) -> 0 \tr1 = socket(AF_VSOCK, SOCK_STREAM, 0) \tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 \taccept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90139", "url": "https://ubuntu.com/security/CVE-2026-90139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: check for NULL root inode in fuse_fill_super_submount fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89776", "url": "https://ubuntu.com/security/CVE-2026-89776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90148", "url": "https://ubuntu.com/security/CVE-2026-90148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90150", "url": "https://ubuntu.com/security/CVE-2026-90150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/blocklayout: Fix device leaks on parse failure bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90152", "url": "https://ubuntu.com/security/CVE-2026-90152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix session leak in ksmbd_session_register() See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90153", "url": "https://ubuntu.com/security/CVE-2026-90153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90158", "url": "https://ubuntu.com/security/CVE-2026-90158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: m68k: nfcon: Do not call console_is_registered() in nfcon_device() Since 7c2af0f634f1 (\"tty: tty_io: use console_list_lock for list synchronization\") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90159", "url": "https://ubuntu.com/security/CVE-2026-90159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90166", "url": "https://ubuntu.com/security/CVE-2026-90166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90169", "url": "https://ubuntu.com/security/CVE-2026-90169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: free preauth sessions on connection teardown SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90170", "url": "https://ubuntu.com/security/CVE-2026-90170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90175", "url": "https://ubuntu.com/security/CVE-2026-90175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm \"pool-0\", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90176", "url": "https://ubuntu.com/security/CVE-2026-90176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90178", "url": "https://ubuntu.com/security/CVE-2026-90178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90180", "url": "https://ubuntu.com/security/CVE-2026-90180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90184", "url": "https://ubuntu.com/security/CVE-2026-90184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90185", "url": "https://ubuntu.com/security/CVE-2026-90185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under \"lock\" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take \"lock\" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90186", "url": "https://ubuntu.com/security/CVE-2026-90186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: reject per-device queue resize for shared tag set When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90187", "url": "https://ubuntu.com/security/CVE-2026-90187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free zones array on device power-off null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90188", "url": "https://ubuntu.com/security/CVE-2026-90188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free global tag_set on init error path If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set).", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90189", "url": "https://ubuntu.com/security/CVE-2026-90189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90190", "url": "https://ubuntu.com/security/CVE-2026-90190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: use DEFINE_MUTEX for the file-scope mutex In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90194", "url": "https://ubuntu.com/security/CVE-2026-90194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: fix bus ID cleanup on device_add() failures When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90196", "url": "https://ubuntu.com/security/CVE-2026-90196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: validate topology volume range before allocation SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 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 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90199", "url": "https://ubuntu.com/security/CVE-2026-90199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject out-of-range evcn in mi_enum_attr() In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: \tif (svcn > evcn + 1) goto out; When evcn is U64_MAX the \"evcn + 1\" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing \"svcn > evcn + 1\" test still tolerates the sentinel (\"0 > 0\" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the \"evcn + 1\" wraparound. svcn does not need its own bound: once evcn < nbits, \"svcn > evcn + 1\" implies svcn <= nbits. [almaz.alexandrovich@paragon-software.com: fixed evcn check]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90200", "url": "https://ubuntu.com/security/CVE-2026-90200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: \tif (mlcn * sct_per_clst >= sectors || \t mlcn2 * sct_per_clst >= sectors) \t\tgoto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in \tsbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90207", "url": "https://ubuntu.com/security/CVE-2026-90207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize input teardown with event_input snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): \tsnd_rawmidi_input_trigger(up=0) \t\t\t\t\tsnd_midi_input_event() \t\t\t\t\t -> snd_rawmidi_kernel_read() \t\t\t\t\t -> snd_rawmidi_input_trigger(up=1) \t -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: \tUnable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 \tCall trace: \t snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) \t snd_rawmidi_input_event_work+0x1c/0x2c \t process_one_work+0x150/0x3a4 \t worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad (\"ALSA: seq: midi: Serialize output teardown with event_input\") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90213", "url": "https://ubuntu.com/security/CVE-2026-90213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix memory leak in error path of build_tree() In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90220", "url": "https://ubuntu.com/security/CVE-2026-90220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Don't leak the extension cell pointer in the bounce payload The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e (\"ALSA: seq: Clear variable event pointer on read\") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90227", "url": "https://ubuntu.com/security/CVE-2026-90227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90229", "url": "https://ubuntu.com/security/CVE-2026-90229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Destroy the admin queue on removal The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90230", "url": "https://ubuntu.com/security/CVE-2026-90230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90235", "url": "https://ubuntu.com/security/CVE-2026-90235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90250", "url": "https://ubuntu.com/security/CVE-2026-90250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix storage null-ptr-deref after replacing prog Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90253", "url": "https://ubuntu.com/security/CVE-2026-90253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90254", "url": "https://ubuntu.com/security/CVE-2026-90254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90255", "url": "https://ubuntu.com/security/CVE-2026-90255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 (\"Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks\"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90262", "url": "https://ubuntu.com/security/CVE-2026-90262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: retry verity reads for not-uptodate Merkle folios btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90275", "url": "https://ubuntu.com/security/CVE-2026-90275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d (\"md: don't quiesce in mddev_suspend()\") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 (\"md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()\"), also triggered by b39f35ebe86d.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90279", "url": "https://ubuntu.com/security/CVE-2026-90279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90280", "url": "https://ubuntu.com/security/CVE-2026-90280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90282", "url": "https://ubuntu.com/security/CVE-2026-90282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90287", "url": "https://ubuntu.com/security/CVE-2026-90287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: sunplus: fix error handling in sp_uphy_init() Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90291", "url": "https://ubuntu.com/security/CVE-2026-90291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module/dups: Fix use-after-free in kmod_dup_req lifetime handling The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) 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 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 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 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90308", "url": "https://ubuntu.com/security/CVE-2026-90308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold QP references for AE and CM processing AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90309", "url": "https://ubuntu.com/security/CVE-2026-90309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold CQ references when processing EQ events EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90313", "url": "https://ubuntu.com/security/CVE-2026-90313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90322", "url": "https://ubuntu.com/security/CVE-2026-90322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90325", "url": "https://ubuntu.com/security/CVE-2026-90325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: skip dying blkg in blkcg_activate_policy() When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90352", "url": "https://ubuntu.com/security/CVE-2026-90352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: release hif2 reference on probe IRQ failure The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90353", "url": "https://ubuntu.com/security/CVE-2026-90353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix ext PHY use-after-free on register error path After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90354", "url": "https://ubuntu.com/security/CVE-2026-90354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix double hif2 init on the non-WED path mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90357", "url": "https://ubuntu.com/security/CVE-2026-90357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90358", "url": "https://ubuntu.com/security/CVE-2026-90358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, x86: Fix trampoline stack size for 128-bit arguments btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90364", "url": "https://ubuntu.com/security/CVE-2026-90364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Unregister cpufreq notifier on init failure acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90366", "url": "https://ubuntu.com/security/CVE-2026-90366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90368", "url": "https://ubuntu.com/security/CVE-2026-90368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unwind state on add_interface failure When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90370", "url": "https://ubuntu.com/security/CVE-2026-90370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90374", "url": "https://ubuntu.com/security/CVE-2026-90374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90375", "url": "https://ubuntu.com/security/CVE-2026-90375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix non-AQL packet accounting for MLO stations __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90383", "url": "https://ubuntu.com/security/CVE-2026-90383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: sgi-gru: remove interrupt-context page-table walks The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90385", "url": "https://ubuntu.com/security/CVE-2026-90385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: create serial pool adding rdev to array with serialize_policy=1 The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90387", "url": "https://ubuntu.com/security/CVE-2026-90387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90389", "url": "https://ubuntu.com/security/CVE-2026-90389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: scope memalloc_noio to allocation critical sections Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90390", "url": "https://ubuntu.com/security/CVE-2026-90390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90392", "url": "https://ubuntu.com/security/CVE-2026-90392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90397", "url": "https://ubuntu.com/security/CVE-2026-90397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90398", "url": "https://ubuntu.com/security/CVE-2026-90398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90399", "url": "https://ubuntu.com/security/CVE-2026-90399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90400", "url": "https://ubuntu.com/security/CVE-2026-90400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90404", "url": "https://ubuntu.com/security/CVE-2026-90404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_debugfs: Unregister panic notifier cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90407", "url": "https://ubuntu.com/security/CVE-2026-90407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90410", "url": "https://ubuntu.com/security/CVE-2026-90410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: davinci: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90418", "url": "https://ubuntu.com/security/CVE-2026-90418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90433", "url": "https://ubuntu.com/security/CVE-2026-90433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: oc-tiny: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92477", "url": "https://ubuntu.com/security/CVE-2026-92477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: debugfs: Reserve space for a string terminator ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92481", "url": "https://ubuntu.com/security/CVE-2026-92481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92484", "url": "https://ubuntu.com/security/CVE-2026-92484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix use-after-free in find_pos_and_ways() error path The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92488", "url": "https://ubuntu.com/security/CVE-2026-92488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: complete object teardown when the destroy command fails erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92489", "url": "https://ubuntu.com/security/CVE-2026-92489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix skb double-free in xfrm_dev_direct_output() A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92490", "url": "https://ubuntu.com/security/CVE-2026-92490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unrequest devices if driver registration fails scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92495", "url": "https://ubuntu.com/security/CVE-2026-92495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92497", "url": "https://ubuntu.com/security/CVE-2026-92497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92506", "url": "https://ubuntu.com/security/CVE-2026-92506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92507", "url": "https://ubuntu.com/security/CVE-2026-92507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_dealloc_pd_user() When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92509", "url": "https://ubuntu.com/security/CVE-2026-92509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in counter_release() When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92510", "url": "https://ubuntu.com/security/CVE-2026-92510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_srq_user() When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92511", "url": "https://ubuntu.com/security/CVE-2026-92511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_cq_user() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92512", "url": "https://ubuntu.com/security/CVE-2026-92512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-74334", "url": "https://ubuntu.com/security/CVE-2026-74334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Fix locking when accessing mr->pd Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-92514", "url": "https://ubuntu.com/security/CVE-2026-92514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Fix CEQ tasklet use-after-free on removal Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92519", "url": "https://ubuntu.com/security/CVE-2026-92519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix memory leak in bpf_jit_free When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92523", "url": "https://ubuntu.com/security/CVE-2026-92523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: validate dynamic counter attribute length RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92525", "url": "https://ubuntu.com/security/CVE-2026-92525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93042", "url": "https://ubuntu.com/security/CVE-2026-93042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the \"Terminate APIs\" section of Documentation/driver-api/dmaengine/client.rst: \"No callback functions will be called for any incomplete transfers.\" dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93050", "url": "https://ubuntu.com/security/CVE-2026-93050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a \"removed\" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93062", "url": "https://ubuntu.com/security/CVE-2026-93062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93063", "url": "https://ubuntu.com/security/CVE-2026-93063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93064", "url": "https://ubuntu.com/security/CVE-2026-93064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93065", "url": "https://ubuntu.com/security/CVE-2026-93065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93072", "url": "https://ubuntu.com/security/CVE-2026-93072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93073", "url": "https://ubuntu.com/security/CVE-2026-93073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93083", "url": "https://ubuntu.com/security/CVE-2026-93083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93084", "url": "https://ubuntu.com/security/CVE-2026-93084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93085", "url": "https://ubuntu.com/security/CVE-2026-93085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93086", "url": "https://ubuntu.com/security/CVE-2026-93086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93089", "url": "https://ubuntu.com/security/CVE-2026-93089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93090", "url": "https://ubuntu.com/security/CVE-2026-93090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93092", "url": "https://ubuntu.com/security/CVE-2026-93092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93093", "url": "https://ubuntu.com/security/CVE-2026-93093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-90048", "url": "https://ubuntu.com/security/CVE-2026-90048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2024-52560", "url": "https://ubuntu.com/security/CVE-2024-52560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr() Extended the `mi_enum_attr()` function interface with an additional parameter, `struct ntfs_inode *ni`, to allow marking the inode as bad as soon as an error is detected.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-93097", "url": "https://ubuntu.com/security/CVE-2026-93097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing \"Protect against an uncleared _FLAG_MORE\" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93101", "url": "https://ubuntu.com/security/CVE-2026-93101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93107", "url": "https://ubuntu.com/security/CVE-2026-93107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e (\"RDMA/rxe: Cleanup reset state handling in rxe_resp.c\") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93113", "url": "https://ubuntu.com/security/CVE-2026-93113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93117", "url": "https://ubuntu.com/security/CVE-2026-93117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93118", "url": "https://ubuntu.com/security/CVE-2026-93118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: check endpoint DMA allocation ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93119", "url": "https://ubuntu.com/security/CVE-2026-93119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93126", "url": "https://ubuntu.com/security/CVE-2026-93126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_adsp: Fix reference leak for device node When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93136", "url": "https://ubuntu.com/security/CVE-2026-93136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93137", "url": "https://ubuntu.com/security/CVE-2026-93137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 (\"bpf: fix mm lifecycle in open-coded task_vma iterator\"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93142", "url": "https://ubuntu.com/security/CVE-2026-93142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of \"priv->zone\". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93149", "url": "https://ubuntu.com/security/CVE-2026-93149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93150", "url": "https://ubuntu.com/security/CVE-2026-93150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 (\"sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets\"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93152", "url": "https://ubuntu.com/security/CVE-2026-93152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93155", "url": "https://ubuntu.com/security/CVE-2026-93155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93156", "url": "https://ubuntu.com/security/CVE-2026-93156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93162", "url": "https://ubuntu.com/security/CVE-2026-93162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93163", "url": "https://ubuntu.com/security/CVE-2026-93163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93172", "url": "https://ubuntu.com/security/CVE-2026-93172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93174", "url": "https://ubuntu.com/security/CVE-2026-93174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93182", "url": "https://ubuntu.com/security/CVE-2026-93182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93184", "url": "https://ubuntu.com/security/CVE-2026-93184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_audmix: rework runtime PM handling in probe After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93186", "url": "https://ubuntu.com/security/CVE-2026-93186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Clamp mailbox output allocation to the payload size CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93190", "url": "https://ubuntu.com/security/CVE-2026-93190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. \tmemcpy(caps_desc.pdo, resp->source_cap_pdos, \t sizeof(u32) * resp->source_cap_count); \t... \tmemcpy(caps_desc.pdo, resp->sink_cap_pdos, \t sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93192", "url": "https://ubuntu.com/security/CVE-2026-93192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Clear queue->active_job when v3d_fence_create() fails The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-23137", "url": "https://ubuntu.com/security/CVE-2026-23137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: unittest: Fix memory leak in unittest_data_add() In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak. Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths. For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.", "cve_priority": "low", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-89970", "url": "https://ubuntu.com/security/CVE-2026-89970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-64210", "url": "https://ubuntu.com/security/CVE-2026-64210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix unlocked writing to ICOSQ During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-89794", "url": "https://ubuntu.com/security/CVE-2026-89794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80878", "url": "https://ubuntu.com/security/CVE-2026-80878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix leak of ungot volume Fix afs_lookup_volume_rcu() so that it doesn't leak a dying volume if afs_try_get_volume() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-04 17:16:00 UTC" }, { "cve": "CVE-2026-89800", "url": "https://ubuntu.com/security/CVE-2026-89800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89801", "url": "https://ubuntu.com/security/CVE-2026-89801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89802", "url": "https://ubuntu.com/security/CVE-2026-89802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89803", "url": "https://ubuntu.com/security/CVE-2026-89803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: unsubscribe the channel-kill event before the fence context nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: \tif (chan->fence) \t\tnouveau_fence(chan->cli->drm)->context_del(chan); \t... \tnvif_object_dtor(&chan->vram); \tnvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89818", "url": "https://ubuntu.com/security/CVE-2026-89818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier \"header does not fit in BO\" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89819", "url": "https://ubuntu.com/security/CVE-2026-89819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: validate plane degamma LUT size for private color prop Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89822", "url": "https://ubuntu.com/security/CVE-2026-89822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89824", "url": "https://ubuntu.com/security/CVE-2026-89824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-edp: fix i2c adapter leak on probe failure Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89830", "url": "https://ubuntu.com/security/CVE-2026-89830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89834", "url": "https://ubuntu.com/security/CVE-2026-89834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89835", "url": "https://ubuntu.com/security/CVE-2026-89835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid NULL checkpoint thread access in sysfs checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89839", "url": "https://ubuntu.com/security/CVE-2026-89839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the \"system.advise\" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89842", "url": "https://ubuntu.com/security/CVE-2026-89842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89844", "url": "https://ubuntu.com/security/CVE-2026-89844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89848", "url": "https://ubuntu.com/security/CVE-2026-89848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Quiesce response IRQ before freeing request queue qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89857", "url": "https://ubuntu.com/security/CVE-2026-89857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89860", "url": "https://ubuntu.com/security/CVE-2026-89860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Initialize NVMe abort_work once at submission qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89870", "url": "https://ubuntu.com/security/CVE-2026-89870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: zoran: Avoid freeing a registered video_device twice zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89874", "url": "https://ubuntu.com/security/CVE-2026-89874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: avoid deleting unlinked ASC entry on link error v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89877", "url": "https://ubuntu.com/security/CVE-2026-89877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: fix cleanup on resource allocation failure saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89884", "url": "https://ubuntu.com/security/CVE-2026-89884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure 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. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89899", "url": "https://ubuntu.com/security/CVE-2026-89899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: disable delayed work before freeing an interrupted transmit cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89900", "url": "https://ubuntu.com/security/CVE-2026-89900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: core: Fix kmemleak due to missed rc_free_device() call The commit dccc0c3ddf8f (\"media: rc: fix race between unregister and urb/irq callbacks\") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm \"kworker/u16:1\", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89902", "url": "https://ubuntu.com/security/CVE-2026-89902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Avoid preempt count underflow without probe LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89903", "url": "https://ubuntu.com/security/CVE-2026-89903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Do not save/restore percpu base register in rethook trampoline The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89908", "url": "https://ubuntu.com/security/CVE-2026-89908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the \"d -> f, e -> g\" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89909", "url": "https://ubuntu.com/security/CVE-2026-89909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89922", "url": "https://ubuntu.com/security/CVE-2026-89922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Take srcu when importing watchpoint data __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89929", "url": "https://ubuntu.com/security/CVE-2026-89929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89931", "url": "https://ubuntu.com/security/CVE-2026-89931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the \"check\" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89933", "url": "https://ubuntu.com/security/CVE-2026-89933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in \"iio->name = id->name\" and crashes the kernel during probe. The IIO device name is always \"dps310\", so set it directly and drop the now-unused device-id lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89934", "url": "https://ubuntu.com/security/CVE-2026-89934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89938", "url": "https://ubuntu.com/security/CVE-2026-89938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89944", "url": "https://ubuntu.com/security/CVE-2026-89944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89950", "url": "https://ubuntu.com/security/CVE-2026-89950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89955", "url": "https://ubuntu.com/security/CVE-2026-89955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix NULL deref in status_show() during queue probe When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89957", "url": "https://ubuntu.com/security/CVE-2026-89957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89958", "url": "https://ubuntu.com/security/CVE-2026-89958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89959", "url": "https://ubuntu.com/security/CVE-2026-89959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89960", "url": "https://ubuntu.com/security/CVE-2026-89960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89961", "url": "https://ubuntu.com/security/CVE-2026-89961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89962", "url": "https://ubuntu.com/security/CVE-2026-89962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Prevent kexec range truncation Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89975", "url": "https://ubuntu.com/security/CVE-2026-89975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing \tdhchap_secret=BAD or \tdhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89988", "url": "https://ubuntu.com/security/CVE-2026-89988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kprobes: Protect kprobe_blacklist with RCU __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89992", "url": "https://ubuntu.com/security/CVE-2026-89992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: dt_idle_genpd: kfree() the original name allocation dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89995", "url": "https://ubuntu.com/security/CVE-2026-89995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-direct: return struct page from dma_direct_alloc_from_pool() Commit 5b138c534fda (\"dma-direct: factor out a dma_direct_alloc_from_pool helper\") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89998", "url": "https://ubuntu.com/security/CVE-2026-89998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix race when loading and unloading a table If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90003", "url": "https://ubuntu.com/security/CVE-2026-90003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message]", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89793", "url": "https://ubuntu.com/security/CVE-2026-89793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: clear VM_MAYWRITE on read-only ublk char device mmap ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.", "cve_priority": "medium", "cve_public_date": "2026-09-16 10:16:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90021", "url": "https://ubuntu.com/security/CVE-2026-90021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90022", "url": "https://ubuntu.com/security/CVE-2026-90022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi2: fix use-after-free in string attribute show path f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90024", "url": "https://ubuntu.com/security/CVE-2026-90024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90026", "url": "https://ubuntu.com/security/CVE-2026-90026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: cancel reset_work on stop pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90035", "url": "https://ubuntu.com/security/CVE-2026-90035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80933", "url": "https://ubuntu.com/security/CVE-2026-80933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate default EEPROM firmware size The default EEPROM firmware is parsed and copied as a full EEPROM without checking its length. A truncated file can make the driver read beyond the firmware buffer during variant validation or the fallback copy. Reject files shorter than MT7996_EEPROM_SIZE before parsing or copying the firmware.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-53250", "url": "https://ubuntu.com/security/CVE-2026-53250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path. Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment. Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2024-56639", "url": "https://ubuntu.com/security/CVE-2024-56639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: must allocate more bytes for RedBox support Blamed commit forgot to change hsr_init_skb() to allocate larger skb for RedBox case. Indeed, send_hsr_supervision_frame() will add two additional components (struct hsr_sup_tlv and struct hsr_sup_payload) syzbot reported the following crash: skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206 Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_over_panic net/core/skbuff.c:211 [inline] skb_put+0x174/0x1b0 net/core/skbuff.c:2617 send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342 hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436 call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794 expire_timers kernel/time/timer.c:1845 [inline] __run_timers+0x6e8/0x930 kernel/time/timer.c:2419 __run_timer_base kernel/time/timer.c:2430 [inline] __run_timer_base kernel/time/timer.c:2423 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2439 run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449 handle_softirqs+0x213/0x8f0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0xbb/0x120 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-23201", "url": "https://ubuntu.com/security/CVE-2026-23201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix oops due to invalid pointer for kfree() in parse_longname() This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running `ls /mnt/my_ceph/.snap`. The variable str is guarded by __free(kfree), but advanced by one for skipping the initial '_' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer. Steps to reproduce: 1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase) 2. Add cephfs mount to fstab $ echo \"samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0\" >> /etc/fstab 3. Reboot the system $ systemctl reboot 4. Check if it's really mounted $ mount | grep stuff 5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap Now ls hangs forever and the kernel log shows the oops.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37833", "url": "https://ubuntu.com/security/CVE-2025-37833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error.", "cve_priority": "low", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80947", "url": "https://ubuntu.com/security/CVE-2026-80947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop rtl8xxxu arms rx_urb_wq from the RX completion path: rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which queues it on rx_urb_pending_list and, once the list grows past RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq. The worker rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(), which anchors it on rx_anchor and dereferences priv->udev. rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog, update_beacon_work) but never cancels rx_urb_wq, so a worker armed during the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect. There are two teardown races to close: * rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock but called schedule_work() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedule_work() after rtl8xxxu_stop() had set shutdown and cancel_work_sync() had already returned, arming the worker to run after the teardown. Move schedule_work() under the same !shutdown branch so the arming decision is atomic with the shutdown check. * rtl8xxxu_rx_urb_work() anchors every URB it drained back onto rx_anchor through rtl8xxxu_submit_rx_urb(). A worker still running when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a URB that escaped the kill. In rtl8xxxu_stop(), call cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is drained first. After priv->shutdown is set under rx_urb_lock, completions can no longer queue rx_urb_wq. cancel_work_sync() then drains the last queued or running worker, and the following usb_kill_anchored_urbs() kills the URBs it may have submitted. rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw() guarantees .stop() runs for a live interface before ieee80211_free_hw() frees priv. The probe error path needs no cancel: rx_urb_wq is INIT_WORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211_register_hw() succeeds. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89771", "url": "https://ubuntu.com/security/CVE-2026-89771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix subbuf resize race with ring buffer readers trace_buffer subbuf_size is read lockless in ring_buffer_read_page() and ring_buffer_read_start(), while it can simultaneously be resized with ring_buffer_subbuf_order_set(). Instead of trace_buffer::subbuf_size, use bpage::order in ring_buffer_read_start() and ring_buffer_read_page(). In ring_buffer_read_start(), even with resize_disabled, there is still a possibility of a race with a buffer modification. Hold the trace_buffer mutex to synchronise with any pending ring buffer order modification. trace_buffer::subbuf_size is now actually useless, remove it. Also, create accessors rb_subbuf_capacity() and rb_page_capacity() which return the actual size available for storing events, while rb_subbuf_size() returns the actual subbuf page-size.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80974", "url": "https://ubuntu.com/security/CVE-2026-80974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix potential memory leaks during remove The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree().", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80979", "url": "https://ubuntu.com/security/CVE-2026-80979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: unregister the connection before draining the rx tasklet smc_conn_free() calls smc_ism_unset_conn() only while the link group is still on its device list, and never sets conn->killed. smc_lgr_terminate_sched() unlinks the group immediately and defers killing its connections to a work item, so a connection freed in that window keeps its smcd->conn[] slot with both gates in smcd_handle_irq() open, and the device can re-arm the receive tasklet after tasklet_kill() has returned. On the DMB-nocopy path the ghost send buffer is freed right after that drain, so the re-armed tasklet dereferences it. Unregister unconditionally and drain before the detach at both teardown sites, mirroring rmb_desc, which smc_buf_unuse() releases after the drain. Clear conn->sndbuf_desc before freeing it as well, so a reader that samples the pointer cannot get one that is already freed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80982", "url": "https://ubuntu.com/security/CVE-2026-80982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Take the socket lock first and test conn->freed instead. smc_conn_free() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80984", "url": "https://ubuntu.com/security/CVE-2026-80984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not dereference an unset send buffer on the SMC-D teardown path smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80989", "url": "https://ubuntu.com/security/CVE-2026-80989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Mark the connection down when bringing it up fails Every failure path in tbnet_connected_work() undoes its own work and returns without clearing login_sent, so the connection still looks established. The next tbnet_tear_down() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a dev_WARN() and fatal under panic_on_warn, and it releases net->remote_transmit_path even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is still using. Clear login_sent on those paths. That is enough for tbnet_tear_down() to leave the unwound state alone, and login_received has to stay set: it records that the peer has logged in and carries the transmit path it gave us, which nothing on this side can make the peer send again. Two things change beyond keeping the teardown out of the way: the logout request in that block is no longer sent, and the peer's next login request now re-queues our login work rather than connected_work, giving the connection a fresh login instead of a retry on stale state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80990", "url": "https://ubuntu.com/security/CVE-2026-80990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Release the Rx HopID that was handed out on mismatch tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it. Release the id when it is not the one we asked for, the same way the error unwind at the end of the function releases the expected one.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80991", "url": "https://ubuntu.com/security/CVE-2026-80991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: serialize PTP clock teardown ravb_ptp_interrupt() can race with ravb_ptp_stop() and pass the clock to ptp_clock_event() while ptp_clock_unregister() is freeing it. This can lead to a use-after-free. Use READ_ONCE() and WRITE_ONCE() for lockless access to the clock pointer. Atomically detach it with xchg() before disabling PTP interrupts, then synchronize all IRQs which can invoke ravb_ptp_interrupt() before unregistering the detached clock. A handler which read the old pointer completes before the clock is unregistered, while later handlers read NULL and skip the event.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80992", "url": "https://ubuntu.com/security/CVE-2026-80992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: avoid dereferencing an invalid PTP clock The PTP clock is unavailable before the first open, so querying its index can dereference a NULL pointer. Registration failures can also leave an error pointer in priv->ptp.clock. Cache the PHC index separately and report -1 while no clock is registered. Normalize registration errors to NULL and preserve the static timestamping capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80996", "url": "https://ubuntu.com/security/CVE-2026-80996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: l2tp: do not propagate multicast notification errors The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80999", "url": "https://ubuntu.com/security/CVE-2026-80999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89439", "url": "https://ubuntu.com/security/CVE-2026-89439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Add a NULL check for sst_inst[] To be consistent with other places, add a NULL check for failed socket loading by checking isst_common.sst_inst[].", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81011", "url": "https://ubuntu.com/security/CVE-2026-81011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: pass validated element count to package parsers The per-type package parsers are handed the wrong element count. hp_init_bios_package_attribute() validates obj->package.count and then calls one of the five hp_populate_*_package_data() wrappers (string, integer, enumeration, ordered list, password). Each wrapper forwards a count to its hp_populate_*_elements_from_package() parser, but instead of forwarding the validated obj->package.count it derives the count from elements[0]. elements[0] is the NAME field and is always an ACPI_TYPE_STRING, so reading ->package.count from it in fact reads ->string.length through the union acpi_object. The parsers thus bound themselves against the length of the name string rather than against the real number of elements in the package. This is safe today because hp_init_bios_package_attribute() refuses any package that has fewer than the type's element count, so a parser only ever runs on a full package and never reads past it regardless of the bogus bound. An upcoming change relaxes that check to accept shorter packages. Once a parser can receive fewer elements than its per-type count, a bound taken from the name length no longer reflects the array size, and the \"elem < count\" loop conditions and \"elem + n >= count\" sub-loop guards read past the end of elements[] - an out-of-bounds heap read. Forward the validated obj->package.count to every *_package_data() wrapper so the parsers bound themselves against the real package size. This does not change behaviour for the packages that enumerate correctly today and is a prerequisite for accepting shorter packages safely.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81012", "url": "https://ubuntu.com/security/CVE-2026-81012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer() hp_get_string_from_buffer() clamps the converted string length against the destination buffer size with \"size > dst_size\", so when the converted length is exactly equal to dst_size, conv_dst_size is left at dst_size and the unconditional NUL terminator write \tdst[conv_dst_size] = 0; lands one byte past the destination buffer. This is the same shape of bug as the previously fixed off-by-one in hp_convert_hexstr_to_str(): the buffer is sized correctly for the content, but the terminator write is never checked against that size. Fix by changing the comparison to \">=\" so conv_dst_size is always left with room for the terminator. All fixed-size destinations that reach this function (path[512], current_value[512], current_password/current_value[64], and the per-entry buffers in encodings[][512] and prerequisites[][512]) are affected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81013", "url": "https://ubuntu.com/security/CVE-2026-81013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix heap OOB read on empty password write validate_password_input() computes length = strlen(buf) and then checks buf[length - 1] to strip a trailing newline, without checking that length is nonzero first. Writing an empty string (a bare '\\n') to current_password or new_password gives length == 0, and buf[length - 1] reads buf[-1], one byte before the heap allocation holding the copied input. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] Read of size 1 at addr ffff88811bd8da9f by task sh/13740 ... store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... The buggy address is located 23 bytes to the right of allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88) Reproduced identically via new_password_store. Execution continues past the bad read (the garbage byte only affects whether \"length\" is decremented by one), so the write completes and returns success; this is a pure information read past the buffer, not a crash, but it is still an out-of-bounds access KASAN correctly flags. Fix by only checking buf[length - 1] when length is nonzero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81014", "url": "https://ubuntu.com/security/CVE-2026-81014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store() sk_store() and kek_store() strip a trailing newline from the sysfs write before allocating the key buffer: \tlength = count; \tif (buf[length - 1] == '\\n') \t\tlength--; \tbioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL); but then pass the original \"count\" (not \"length\") as the copy size to hp_wmi_perform_query(), which memcpy()s that many bytes out of the \"length\"-sized allocation, reading one byte past it whenever the write ends in a newline, the normal case for a shell \"echo\" into sysfs. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg] Read of size 28 at addr ffff88813c8e2b80 by task python3/16022 ... sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... The buggy address is located 0 bytes inside of allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b) Reproduced identically for kek_store, and at multiple write sizes (28, 57, 201 bytes), each time reading exactly one byte past a kmemdup() allocation one byte smaller than the write. Fix by passing \"length\" instead of \"count\" to hp_wmi_perform_query() in both functions.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89438", "url": "https://ubuntu.com/security/CVE-2026-89438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate logical CPU id and clos id Validate max CLOS ID and logical CPU ID for core power feature. Reject any clos level or logical CPU number greater than the supported maximum. These are used to calculate MMIO offset.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89442", "url": "https://ubuntu.com/security/CVE-2026-89442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate socket ID in clos_assoc ioctl isst_if_clos_assoc() validates the user-supplied socket_id with 'socket_id > topology_max_packages()', but isst_common.sst_inst[] is allocated with topology_max_packages() entries, so the valid index range is [0, topology_max_packages()). The '>' comparison lets socket_id == topology_max_packages() pass and index one entry past the array. In addition, isst_common.sst_inst[socket_id] is NULL for an in-range package that has no bound TPMI SST instance, and the pointer is used without a NULL check. Both the out-of-bounds entry and the NULL pointer are then dereferenced by map_partition_power_domain_id() and the following power_domain_info access. Reject socket_id >= topology_max_packages() and a NULL sst_inst, matching the checks already performed by get_instance().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89443", "url": "https://ubuntu.com/security/CVE-2026-89443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate level in perf mask ioctls isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask() use the user-provided level as an index into perf_levels[] via _read_pp_level_info() and _read_bf_level_info(), but neither helper validates it first. The adjacent level-info helpers reject levels above max_level before reading the same per-level register block. Add the same bounds checks to the mask helpers, and reject disabled SST-PP levels in isst_if_get_perf_level_mask() to match isst_if_get_perf_level_info(). This prevents out-of-bounds reads from the per-level offset table on invalid ioctl input.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89448", "url": "https://ubuntu.com/security/CVE-2026-89448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Force requesting ACS when tboot is enabled Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu().", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89451", "url": "https://ubuntu.com/security/CVE-2026-89451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/sva: Set handle->dev before the SVA handle is visible iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommu_sva_unbind_device() can then dereference it via handle->dev->iommu_group. Initialize handle->dev before releasing iommu_sva_lock so any visible SVA handle is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89462", "url": "https://ubuntu.com/security/CVE-2026-89462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: propagate register read errors max17040_get_vcell() and max17040_get_soc() ignore errors returned by regmap_read(). When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as a valid voltage or state of charge. The polling worker can also replace the cached state of charge with the bogus value and emit a spurious change event. Propagate read errors through the power supply get_property callback and keep the last valid cached state of charge when polling fails.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89465", "url": "https://ubuntu.com/security/CVE-2026-89465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: quiesce delayed work before teardown The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89466", "url": "https://ubuntu.com/security/CVE-2026-89466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: qcom_battmgr: terminate the strings from firmware The qcom_battmgr_sc8280xp_strcpy() takes a Pascal-style string when the firmware sends one. Otherwise it copies all BATTMGR_STRING_LEN bytes and leaves the destination without a terminator. Those destinations are model_number, serial_number and oem_info, each BATTMGR_STRING_LEN and declared next to each other. They go out to user space as val->strval, which power_supply_format_property() prints with \"%s\", so a firmware string that fills the whole field makes that read run into the following members. Use strscpy() so the copy always terminates, the way the SM8350 path already does for the same field.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89468", "url": "https://ubuntu.com/security/CVE-2026-89468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8788-charger: fix use-after-free on remove lp8788_charger_remove() flushes charger_work before unregistering the IRQs. An IRQ thread can queue charger_work after flush_work() has returned. The work can then run after devres frees pchg and dereference it in lp8788_charger_event(). Unregister the IRQs first. free_irq() waits for any running threaded handler, so no handler can queue more work afterwards. Then use cancel_work_sync() to cancel pending work or wait for running work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89472", "url": "https://ubuntu.com/security/CVE-2026-89472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: register regulators before exposing sysfs charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available. Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path. Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure). This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89473", "url": "https://ubuntu.com/security/CVE-2026-89473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25890: Fix power_supply reference leak bq25890_fw_probe() acquires a reference to a secondary charger using power_supply_get_by_name(), but the reference is not released on later probe failures or on driver detach. In particular, failures after bq25890_fw_probe() returns successfully, such as a failure in bq25890_hw_init(), also leak the reference. Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89481", "url": "https://ubuntu.com/security/CVE-2026-89481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix host memory disclosure on R2T for a read command nvme_tcp_handle_r2t() does not check the direction of the request the R2T refers to. A malicious controller can send an R2T for a READ and the host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the H2CData header and nvme_tcp_try_send_data() sends the request's data buffer. That buffer is the READ destination, so its contents go to the controller. The command then completes normally and nothing is logged. Against a test controller that answers every READ with an R2T, a 4096 byte buffered read returned all 4096 bytes, split over two R2Ts. The pages contained stale kernel data, including an array of struct page pointers. Reject an R2T for a request that is not a write.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) 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 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] 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 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89484", "url": "https://ubuntu.com/security/CVE-2026-89484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: fix NULL dereference on lockowner allocation failure nlmclnt_locks_init_private() installs NLM file lock operations even when nlmclnt_find_lockowner() fails to allocate a lockowner. nlmclnt_proc() then returns -ENOMEM, but the VFS still tears down the partially initialized file_lock and calls locks_release_private(). That invokes nlmclnt_locks_release_private(), which dereferences fl->fl_u.nfs_fl.owner and crashes because the owner was never installed. Clear fl_ops before attempting to initialize the NLM private state, and install the NLM lock operations only after a lockowner has been allocated successfully.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89567", "url": "https://ubuntu.com/security/CVE-2026-89567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: bound shrinker scans by examined checkpoint buffers The jbd2 shrinker currently accounts only checkpoint buffers that it successfully releases against nr_to_scan. Busy buffers therefore do not consume the scan budget. If a checkpoint transaction contains mostly busy buffers, the shrinker can scan its entire checkpoint list while holding journal->j_list_lock. Large checkpoint lists can result in excessive lock hold times and leave other CPUs spinning on j_list_lock, causing soft lockups or RCU stalls. Pass nr_to_scan into journal_shrink_one_cp_list() and decrement it for every buffer examined, including busy buffers. Pass NULL from checkpoint cleanup paths so their existing full-list behavior is preserved. This restores the scan-budget semantics that existed before journal_shrink_one_cp_list() was changed to always scan a complete checkpoint list.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89536", "url": "https://ubuntu.com/security/CVE-2026-89536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: wait for in-flight client TLS handshake callback xs_tls_handshake_sync() gives xs_tls_handshake_done() a reference to the lower transport before submitting the handshake request. On timeout or signal, the synchronous waiter drops that reference after calling tls_handshake_cancel(). handshake_req_cancel() returns false when handshake_complete() has already marked the request complete. In that case the completion callback can still be running, so dropping the callback-owned reference in the waiter can free the lower transport before xs_tls_handshake_done() stores xprt_err or drops its own reference. If cancellation loses to completion, wait until xs_tls_handshake_done() signals handshake_done and let the callback release its reference. This mirrors the server-side handshake lifetime handling and keeps the timeout or signal return value unchanged.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89539", "url": "https://ubuntu.com/security/CVE-2026-89539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: reject duplicate CREDS_VALUE options gssx_dec_option_array() walks the wire-supplied option array and, for every entry whose name matches CREDS_VALUE, calls gssx_dec_linux_creds() on the same struct svc_cred. That helper unconditionally installs a fresh groups_alloc() result into creds->cr_group_info without releasing whatever pointer was already there: for (i = 0; i < count; i++) { ... decode name ... if (length == sizeof(CREDS_VALUE) && memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) { err = gssx_dec_linux_creds(xdr, creds); ... } } A reply that carries two CREDS_VALUE entries therefore overwrites cr_group_info on the second iteration and orphans the group_info allocated by the first call. The earlier free_creds path only releases the last cr_group_info via free_svc_cred(), so the first allocation's refcount stays at one and its kvmalloc-backed storage is leaked. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply. Fix by tracking whether a CREDS_VALUE option has already been decoded and returning -EINVAL on any subsequent match, so the free_creds path releases the single group_info that was installed.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89547", "url": "https://ubuntu.com/security/CVE-2026-89547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Check svc pool percpu counter allocation __svc_create() initializes three per-pool percpu_counter stats and ignores every return value. On SMP, percpu_counter_init() fails when __alloc_percpu_gfp() cannot satisfy the allocation, leaving the failed counter with fbc->counters == NULL and its embedded raw_spinlock_t, list_head, and count never initialized. __svc_create() returns the half-constructed svc_serv to nfsd, lockd, or the NFS callback service anyway. Once that service is live, the hot-path increments in svc_xprt_enqueue(), svc_handle_xprt(), and svc_pool_wake_idle_thread() reach a counter whose backing pointer is NULL. The pointer is a per-cpu offset, so the access does not fault: it resolves to offset zero of the current CPU's per-cpu area and silently corrupts whatever variable lives there. A /proc/fs/nfsd/pool_stats read walks the same NULL per-cpu storage and returns garbage, and on CONFIG_DEBUG_SPINLOCK or lockdep it splats on the never-initialized lock. Creating the broken service requires a percpu allocation failure during RPC server startup, so it is reachable only by a local administrator under memory pressure or fault injection; a remote peer cannot induce the bad state on its own. Check each percpu_counter_init() return value in __svc_create() and fail when an allocation fails, unwinding the counters already set up in the current pool and in every pool initialized before it. A discrete percpu_counter_destroy() per counter at teardown frees each per-cpu allocation exactly once.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89550", "url": "https://ubuntu.com/security/CVE-2026-89550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division. Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload. Fix by adding a minimum-length check immediately after the existing upper-bound check: if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89552", "url": "https://ubuntu.com/security/CVE-2026-89552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: params: fix charp corruption on allocation failure param_set_charp() stores charp parameters in allocated memory after slab is available, and releases the previous value when the parameter is updated. The previous value is released before the replacement allocation succeeds. If kmalloc_parameter() fails, the setter returns -ENOMEM with the parameter left as NULL. Failing zswap's compressor update before zswap is initialized can later trigger: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strcmp+0x10/0x30 Call Trace: zswap_setup+0x3b1/0x490 zswap_enabled_param_set+0x5b/0xa0 param_attr_store+0x93/0xe0 module_attr_store+0x1c/0x30 kernfs_fop_write_iter+0x116/0x1f0 Allocate and copy the replacement first, then replace the parameter value only after allocation succeeds.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89553", "url": "https://ubuntu.com/security/CVE-2026-89553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/gem: reserve the bo in the info ioctl around the vma lookup In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free. Spotted with the help of Opus 4.6.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80914", "url": "https://ubuntu.com/security/CVE-2026-80914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 (\"Bluetooth: ISO: hold sk properly in iso_conn_ready\"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89574", "url": "https://ubuntu.com/security/CVE-2026-89574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: validate array block headers on read array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89579", "url": "https://ubuntu.com/security/CVE-2026-89579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Harden bloom filter sizing and indexing on 32-bit kernels bloom_map_alloc() has two 32-bit-specific problems when the computed bitmap reaches the U32_MAX fallback case. First, BITS_TO_BYTES(U32_MAX) is evaluated with 32-bit arithmetic. The addition performed by DIV_ROUND_UP wraps, so the map allocates only the fixed-size bloom filter object while keeping bitset_mask == U32_MAX. Subsequent updates can then write past the allocated object. Second, fixing only the allocation size is not sufficient. The bloom hash is a u32, but set_bit() takes a signed long bit number and x86 test_bit() eventually feeds the index to variable_test_bit(long, ...). On 32-bit kernels, hashes in [0x80000000, U32_MAX] therefore become negative bit offsets. x86 bt/bts with a memory operand interpret those offsets relative to the supplied base, so a map with bitset_mask == U32_MAX can read or write before bloom->bitset even after allocating the full 512 MiB bitmap. Keep the U32_MAX fallback, but split each hash into a word pointer and an in-word bit number before calling test_bit() or set_bit(). The bitops argument is then always in [0, BITS_PER_LONG - 1], while BIT_WORD(h) still selects the intended word in the full bitmap. Compute the bitset size from (u64)bitset_mask + 1 before passing the final size to bpf_map_area_alloc(). This fixes the original under-allocation and keeps the allocated storage consistent with the addressable bitset. Exploitation note: local privilege escalation is possible on a 32-bit x86 kernel using the under-allocation bug from a binary with CAP_BPF.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89580", "url": "https://ubuntu.com/security/CVE-2026-89580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in __bpf_get_stack get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below. A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy_len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build_id path. The rcu_read_lock() taken here alone does not prevent this. It is only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call_rcu()) and does nothing to stop another task from reusing the entry. Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max_depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt_disable() also subsumes the buffer-lifetime guarantee the rcu_read_lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call_rcu() reclaim. [ changed Fixes: commit ]", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89583", "url": "https://ubuntu.com/security/CVE-2026-89583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix OOB read in eir_get_service_data() eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a \"field\" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89587", "url": "https://ubuntu.com/security/CVE-2026-89587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: pfr_update: fix stack buffer overflow in query_capability() query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89588", "url": "https://ubuntu.com/security/CVE-2026-89588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: GHES: fix ARM section length accounting after header In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89598", "url": "https://ubuntu.com/security/CVE-2026-89598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: ssd1307fb: defer I2C transfers from damage callbacks The fbdev damage callbacks may run from fbcon while printk has disabled preemption. They currently update the display synchronously, which enters the sleeping I2C transfer path from atomic context. A complete report from an RK3566 system follows: [ 258.129004] watchdog: watchdog0: watchdog did not stop! [ 258.129067] BUG: scheduling while atomic: systemd/1/0x00000003 [ 258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] Preemption disabled at: [ 258.129216] [] vprintk_emit+0x11c/0x340 [ 258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT) [ 258.129243] Call trace: [ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [ 258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [ 258.129313] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [ 258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra.0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [ 258.129392] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [ 258.129409] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [ 258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ cut here ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [ 258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871 preempt_count_sub+0x9c/0x148 [ 258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89604", "url": "https://ubuntu.com/security/CVE-2026-89604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Rate limit statfs() handler Ravi reports that statfs() may be called by unprivileged users on the efivarfs mount point, which may result in a flood of calls to the QueryVariableInfo() runtime service. These calls are disproportionately costly on x86 systems where the variable store is backed by SMM, as each SMM entry requires a rendez-vous of all the CPUs. So rate limit the calls to QueryVariableInfo() at twice per second, and return the most recently obtained value for calls that are elided.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89618", "url": "https://ubuntu.com/security/CVE-2026-89618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Initialize ei->children and ei->list in init_ei() eventfs_create_dir() allocates the eventfs_inode and initializes it with init_ei(). But this does not initialize the eventfs_inode list_heads. If the eventfs_create_dir() fails due to memory pressure, it will call free_ei() before it initialized the lists, and that checks to make sure the eventfs_inode has no children. But because the list wasn't initialized, it will give a false warning. Fix it by moving the list initialization into init_ei(). [ Rewrote change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89634", "url": "https://ubuntu.com/security/CVE-2026-89634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix ALIGN() overflow in symlink_data() error context loop The check added by commit 7d9a7f1f96cd (\"smb/client: fix possible infinite loop and oob read in symlink_data()\") compared the post-ALIGN length against the remaining buffer, but ALIGN() itself can overflow: for ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8) wraps to 0, so the subsequent bounds check passes, and the loop advances by zero bytes leaving 'p' pointing into stale data. Fix by checking the raw ErrorDataLength against the remaining space before applying ALIGN(), then checking again after. Since raw_len is bounded by the buffer, raw_len + 7 cannot overflow, so the second check is an exact post-alignment bounds guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89636", "url": "https://ubuntu.com/security/CVE-2026-89636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: clear ce->tgthint in free_tgts() When free_tgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cache_dfs_tgt structures. If ce->tgthint is not reset before it is used later, it results in a use-after-free. Set ce->tgthint to NULL in free_tgts() after the elements are freed to reflect that no elements remain.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89640", "url": "https://ubuntu.com/security/CVE-2026-89640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 With len == 0 (clone to EOF), the effective length is computed as: len = src_inode->i_size - off; If off > i_size, this is a negative loff_t, corrupting the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request and inverting the range in filemap_write_and_wait_range(). The existing off >= i_size check fires only after the ioctl has already been sent. Snapshot i_size_read() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > src_size with -EINVAL. Treat off == src_size as a no-op, consistent with __generic_remap_file_range_prep().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89645", "url": "https://ubuntu.com/security/CVE-2026-89645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: drop recovered reloc root refs on recovery failure During relocation recovery, each fs root gets a reference to its relocation root. If loading or adding a later root fails, or if the first transaction commit fails, btrfs_recover_relocation() jumps to out_unset before merge_reloc_roots() and clean_dirty_subvols(). put_reloc_control() drops the list-owned relocation root references, but it does not clear fs_root->reloc_root or drop the references owned by those pointers. Mount cleanup only drops them when BTRFS_FS_ERROR is set, so an error such as -ENOMEM while processing a later root can leave references behind. Keep temporary references to the fs roots associated during recovery. On failure, clear their reloc_root pointers and drop the corresponding references. Once the first transaction commit succeeds, drop only the temporary fs root references and let the normal merge and cleanup paths handle the relocation roots. Fault injection on a pending-relocation image confirmed the cleanup gap. With an injected first-commit failure, 25 fs roots had reloc_root set with fs_error=0. With this fix, the same failure path drops that count to 0 before mount fails.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89647", "url": "https://ubuntu.com/security/CVE-2026-89647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: do not repeat ceph_trim_dentries() if no progress possible ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately. The dir-lease walk made this worse. When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease. `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue. Fix this in three steps: - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is `false`. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via `STOP` at the first fresh lease). - Only return `-EAGAIN` from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead. - After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (`count==0`). There is no reason to keep retrying when we are not over the cap limit and made no progress. Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`. Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in `/proc/lock_stat` (5 minute capture): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 With this patch: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89652", "url": "https://ubuntu.com/security/CVE-2026-89652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89657", "url": "https://ubuntu.com/security/CVE-2026-89657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate OSD extent maps before cursor advance net/ceph/osd_client.c:osd_sparse_read() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUG_ON(!*length) assertion in ceph_msg_data_next() from the client receive path. Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply. Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor. [ idryomov: perform sparse_extent_map_valid() check a bit earlier, in CEPH_SPARSE_READ_DATA_LEN instead of CEPH_SPARSE_READ_DATA_PRE state ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89666", "url": "https://ubuntu.com/security/CVE-2026-89666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC. Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created. tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89671", "url": "https://ubuntu.com/security/CVE-2026-89671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: gate nfs3 setacl by argp->mask nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set: nfs3svc_decode_setaclargs() if (args->mask & NFS_ACL) decode into acl_access if (args->mask & NFS_DFACL) decode into acl_default /* otherwise the pointer stays NULL (pc_argzero) */ nfsd3_proc_setacl() set_posix_acl(.., ACL_TYPE_ACCESS, argp->acl_access) set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default) set_posix_acl(idmap, dentry, type, NULL) is the VFS \"remove this ACL type\" operation. A NULL pointer that means \"the client did not send this arm\" is therefore indistinguishable from \"the client asked to remove this ACL\". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both. The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl. Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89672", "url": "https://ubuntu.com/security/CVE-2026-89672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: gate nfs2 setacl by argp->mask The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode. nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS \"remove this ACL type\" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFS_ACL silently strips the directory's default ACL; mask=0 strips both. This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89680", "url": "https://ubuntu.com/security/CVE-2026-89680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file leak on inter-server COPY setup failure When nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns nfserr_offload_denied directly, bypassing the out: label where release_copy_files() would drop the nf_dst reference taken by nfs4_preprocess_stateid_op(). Each failed inter-server COPY leaks one nfsd_file, pinning file/inode/dentry/vfsmount. Fix by setting status and jumping to out: instead of returning directly.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89686", "url": "https://ubuntu.com/security/CVE-2026-89686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation revoke nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering the BUG_ON. This race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall. When the first client doesn't respond to the recall, the laundromat revokes it. A concurrent LAYOUTGET from any client using the delegation stateid hits the race window. Fix this by taking fi_lock around the fi_deleg_file read in the SC_TYPE_DELEG path, matching the locking discipline of the find_any_file() arm, and replacing the BUG_ON with a graceful error return that cleans up the partially-initialized layout stateid.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89690", "url": "https://ubuntu.com/security/CVE-2026-89690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: defer vfree of compound ops to fix rpc_status UAF The rpc_status netlink dumpit walks every in-flight svc_rqst under rcu_read_lock and, for NFSv4 requests, reads opnums out of args->ops[]. But args->ops is a separate vmalloc buffer freed synchronously by vfree() in nfsd4_release_compoundargs() at the end of every compound. The dumpit's rcu_read_lock pins the svc_rqst struct itself (freed via kfree_rcu), but nothing defers the vfree of the ops buffer across the RCU grace period. A concurrent compound completion can therefore free the buffer while the dumpit is reading it — a use-after-free on vmalloc memory. The trailing seqcount recheck (smp_load_acquire of rq_status_counter) cannot undo a load that already retired against freed memory. Fix by replacing vfree(args->ops) with kvfree_rcu_mightsleep(), which defers the free until after an RCU grace period. This makes the existing rcu_read_lock in the dumpit sufficient to protect the read. The tradeoff is that completed compound ops buffers (up to 200 * sizeof(struct nfsd4_op)) persist in memory slightly longer, across one grace period, before being reclaimed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89691", "url": "https://ubuntu.com/security/CVE-2026-89691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear opcnt on compound arg release to prevent OOB read nfsd4_release_compoundargs() resets args->ops to the inline iops[8] array when the dynamically-allocated ops buffer is freed, but leaves args->opcnt at its original value (which can be up to 200 for NFSv4.1+ compounds). If rq_status_counter is stuck at an odd value (which can happen when nfsd_dispatch() hits an error path after setting it odd), the RPC status dumpit handler reads min(opcnt, 16) entries from args->ops[]. Since iops only has 8 elements and is the last field in struct nfsd4_compoundargs, reading indices 8-15 accesses adjacent slab memory and leaks it to userspace via netlink. Zero opcnt unconditionally in nfsd4_release_compoundargs() so stale compound metadata is never exposed through the status interface. [ cel: Remove the kvfree_rcu_mightsleep() sleep from the exposure window ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89702", "url": "https://ubuntu.com/security/CVE-2026-89702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: size fh_verify server sockaddr slot by xpt_locallen The nfsd_fh_verify and nfsd_fh_verify_err tracepoints declare the server sockaddr slot sized by xpt_remotelen but fill it from xpt_local using xpt_locallen: TP_STRUCT__entry( ... __sockaddr(server, rqstp->rq_xprt->xpt_remotelen) ... ) TP_fast_assign( ... __assign_sockaddr(server, &rqstp->rq_xprt->xpt_local, rqstp->rq_xprt->xpt_locallen); ... ) When xpt_locallen exceeds xpt_remotelen, __assign_sockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xpt_locallen < xpt_remotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers. The write-past-end case is reachable on NFS/UDP. svc_xprt_set_remote() is only called from svc_tcp_accept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svc_create_socket() for UDP calls only svc_xprt_set_local(), so xpt_remotelen stays 0 for the xprt's lifetime. Every fh_verify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xpt_local into a zero-byte slot. The other NFSD tracepoints that record the server address (NFSD_TRACE_PROC_CALL_FIELDS, NFSD_TRACE_PROC_RES_FIELDS, SVC_RQST_ENDPOINT_FIELDS) already size the server slot by xpt_locallen; nfsd_fh_verify and nfsd_fh_verify_err were the only exceptions. Fix by sizing the server slot with xpt_locallen so the declared slot matches the copy length. The client slot and its assignment already agree on xpt_remotelen and are left untouched.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89707", "url": "https://ubuntu.com/security/CVE-2026-89707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release path refs on follow_down() error nfsd_cross_mnt() initializes a local struct path with mntget() and dget() before calling follow_down(). On a negative return the error arm jumps to out without releasing those references: err = follow_down(&path, follow_flags); if (err < 0) goto out; follow_down() never drops the caller's entry-time refs on any error sub-case; for example a pre-cross d_manage() failure leaves path untouched, so the mntget()/dget() taken on entry survive the call. Every other early-exit arm in nfsd_cross_mnt() (other-namespace return, IS_ERR(exp2), and the success tail after the swap) already calls path_put(&path); the err < 0 arm is the lone omission. The leak inflates mnt_count and d_count on each failed cross-mount, blocking umount and pinning dentries against the shrinker, and is reachable by any authenticated NFS client through nfsd_lookup_dentry or the NFSv4 READDIR encode path. Fix by calling path_put(&path) before the goto out in the err < 0 arm so the entry-time refs are released on all follow_down() error returns.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89713", "url": "https://ubuntu.com/security/CVE-2026-89713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: check truncate permission under inode lock nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89735", "url": "https://ubuntu.com/security/CVE-2026-89735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: remove default configfs groups on teardown f_midi2_alloc_inst() creates default configfs child groups for the default endpoint and default block using configfs_add_default_group(), setting their internal refcount to 1. However, during function teardown in f_midi2_free_inst() or EP cleanup in f_midi2_ep_opts_release(), configfs_remove_default_groups() is never called, therefore never dropping the refcount and leaking struct f_midi2_ep_opts and f_midi2_block_opts. Add the missing configfs_remove_default_groups() in the afformentioned functions to free the structs properly.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89738", "url": "https://ubuntu.com/security/CVE-2026-89738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration. Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc. Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and work_struct are never initialized. This does not require a fault; a normal driver unbind can interleave with an already queued work item. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89740", "url": "https://ubuntu.com/security/CVE-2026-89740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: imx: serialize imx_uart_ports[] lifetime imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[] before uart_add_one_port() because console setup uses the table. The entry is not cleared when adding the port fails or after removal, leaving a dangling pointer. A sibling probe can register the shared console through that stale entry. This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a sibling UART, unbinding the console UART and rebinding the sibling. Keep the entry valid through uart_remove_one_port(), then clear it. Protect port addition and removal together with their table updates so sibling operations cannot interleave. Reject an occupied slot rather than clobbering an active port during a duplicate-line probe.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89743", "url": "https://ubuntu.com/security/CVE-2026-89743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: bound the device-reported response length nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported by the NSM device into msg->resp.len without bounding it to the response buffer. A malicious or buggy backend can report a length larger than the response buffer; parse_resp_raw() then copies that many bytes out of the fixed buffer to user space, disclosing adjacent kernel heap (an out-of-bounds read). The request path already floors its length in fill_req_raw(); the response path lacks the symmetric check. Clamp the stored length to the size of the response buffer. Well-behaved devices report no more than the posted buffer size, so conforming traffic is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89744", "url": "https://ubuntu.com/security/CVE-2026-89744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 (\"device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()\").", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89746", "url": "https://ubuntu.com/security/CVE-2026-89746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free with same-name named triggers When two hist triggers on different events are registered with the same name=, the second one reuses the first as named_data. Both are added to tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(), because save_hist_vars() is called before event_trigger_register() while the named reuse is only detected later, in hist_register_trigger(). In the named-data branch hist_register_trigger() then frees the second histogram's hist_data via destroy_hist_data(), but never removes its tr->hist_vars list entry, leaving a dangling pointer and leaking the trace_array reference it holds. A later hist trigger that references a variable makes find_var_file() walk tr->hist_vars and dereference the freed hist_data. The bug is reproducible from userspace by writing three hist triggers to tracefs: cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger The third write panics the kernel: BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix by removing the hist_data from tr->hist_vars and releasing the trace_array reference in the named-data branch of hist_register_trigger() before freeing the hist_data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89747", "url": "https://ubuntu.com/security/CVE-2026-89747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free in trace_pipe read on sub-buffer order change Writing to buffer_subbuf_size_kb calls ring_buffer_subbuf_order_set(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones. Readers of trace_pipe hold pointers into those pages. ring_buffer_peek() looks up an event under cpu_buffer->reader_lock but returns the event pointer after dropping the lock, and peek_next_entry() then calls ring_buffer_event_length() and ring_buffer_event_data() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory: BUG: KASAN: use-after-free in ring_buffer_peek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002 Freed by: free_buffer_page kernel/trace/ring_buffer.c:398 [inline] ring_buffer_subbuf_order_set+0x1325/0x18e0 kernel/trace/ring_buffer.c:7444 buffer_subbuf_size_write+0x182/0x280 kernel/trace/trace.c:8221 Take trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change. This is the lock trace_pipe readers already hold across their entire peek-and-print loop, so the swap can no longer race with a reader that is dereferencing a peeked event.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89750", "url": "https://ubuntu.com/security/CVE-2026-89750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Clear copied tracing state before fork duplication dup_task_struct() copies user_event_mm from the parent into the child, without grabbing a reference to it. user_event_mm_dup() should replace it, but it leaves that copied pointer unmodified if user_event_mm_alloc() fails. When the child exits, user_event_mm_remove() decrements a reference the child never owned, which ultimately frees user_event_mm, while the parent still as a stale pointer to it. This creates a UAF, which KASAN reports as: BUG: KASAN: slab-use-after-free in current_user_event_mm+0x51/0x1d0 Write of size 4 at addr ffff888005010d30 by task init/44 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 current_user_event_mm+0x51/0x1d0 user_events_ioctl+0x82e/0x15c0 __x64_sys_ioctl+0x139/0x1c0 do_syscall_64+0xce/0x450 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 44: __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x180/0x3a0 user_event_mm_alloc+0x3c/0x1f0 current_user_event_mm+0x88/0x1d0 Freed by task 42: __kasan_slab_free+0x43/0x70 kfree+0x13a/0x390 process_one_work+0x696/0xf90 worker_thread+0x420/0xba0 The fix simply clears the copied pointer before any possible failure. In case of failure, the child then has nothing to free.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89751", "url": "https://ubuntu.com/security/CVE-2026-89751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix off-by-one in port I/O handling handle_in() and handle_out() in arch/x86/coco/tdx/tdx.c use: u64 mask = GENMASK(BITS_PER_BYTE * size, 0); GENMASK(h, l) includes bit h. For size=1 (INB), this produces GENMASK(8, 0) = 0x1FF (9 bits) instead of GENMASK(7, 0) = 0xFF (8 bits). The mask is one bit too wide for all I/O sizes. Fix the mask calculation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89756", "url": "https://ubuntu.com/security/CVE-2026-89756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch() migrate_pages_batch() unmaps each folio before moving it, and every unmap runs the mmu_notifier invalidate callbacks. On KVM hosts try_to_migrate() ends up in kvm_mmu_notifier_invalidate_range_start() -> tdp_mmu_zap_leafs(), which is expensive, so unmapping a large batch keeps the CPU busy for a long time. The loop already calls cond_resched(), but on PREEMPTION kernels that is a no-op, and involuntary preemption is not a Tasks-RCU quiescent state. A long batch therefore never reports a quiescent state, and the migrating task (e.g. kcompactd) becomes a Tasks-RCU holdout, stalling the Tasks-RCU grace period for minutes, which is common at Meta fleet: INFO: rcu_tasks detected stalls on tasks: 0000000055349ecc: .. nvcsw: 1157401/1157401 holdout: 1 idle_cpu: -1/56 task:kcompactd0 state:R running task Call Trace: tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread Use cond_resched_tasks_rcu_qs() so a quiescent state is reported even when cond_resched() does nothing. This has also been discussed at [1]", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89759", "url": "https://ubuntu.com/security/CVE-2026-89759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup when scanning task stacks Patch series \"mm/kmemleak: avoid soft lockup when scanning task\", v3. kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads. That prints the following message, depending on the workload+host configuration: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks Patches 2-3 let the scan loops stop early once a scan is interrupted. This patch (of 3): kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point. On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section. Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop(). This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89761", "url": "https://ubuntu.com/security/CVE-2026-89761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix out-of-bounds write when null terminating a label vec aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries. aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger. len comes from the number of \"//&\" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required. The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with \"+ 1 for null terminator entry on vec\". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89762", "url": "https://ubuntu.com/security/CVE-2026-89762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix cred UAF caused by begin_current_label_crit_section() AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label. The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds. So in approximately the following scenario, things go wrong: 1. task begins with (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on for overriding 3. task calls override_creds(), which returns a pointer to the old subjective creds () 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with and drops 2 refs on 7. task leaves AppArmor LSM hook 8. task calls revert_creds() 9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to 10. another task drops the extra reference on that was used for overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-53313", "url": "https://ubuntu.com/security/CVE-2026-53313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)", "cve_priority": "low", "cve_public_date": "2026-06-26 20:17:00 UTC" }, { "cve": "CVE-2026-53113", "url": "https://ubuntu.com/security/CVE-2026-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix memory leaks in beacon template setup The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53102", "url": "https://ubuntu.com/security/CVE-2026-53102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 (\"wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error\") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43344", "url": "https://ubuntu.com/security/CVE-2026-43344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix die ID init and look up bugs In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, uncore_device_to_die() may return -1 when all CPUs associated with the UBOX device are offline. Remove the WARN_ON_ONCE(die_id == -1) check for two reasons: - The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan. - Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error. Separately, when NUMA is disabled on a NUMA-capable platform, pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() to return -1 for all PCI devices. As a result, spr_update_device_location(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree. Fix this by using uncore_pcibus_to_dieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbep_pci2phy_map_init() to be added in spr_uncore_pci_init(). Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where NUMA is expected to be enabled.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-38205", "url": "https://ubuntu.com/security/CVE-2025-38205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1 [Why] If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated then they can lead to a divide by zero in downstream callers like CalculateVMAndRowBytes() [How] Initialize dummy value to a value to avoid divide by zero.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21817", "url": "https://ubuntu.com/security/CVE-2025-21817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mark GFP_NOIO around sysfs ->store() sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused. Fix the issue by marking NOIO around sysfs ->store()", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-22127", "url": "https://ubuntu.com/security/CVE-2025-22127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in prepare_compress_overwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38621", "url": "https://ubuntu.com/security/CVE-2025-38621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: make rdev_addable usable for rcu mode Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-22108", "url": "https://ubuntu.com/security/CVE-2025-22108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Mask the bd_cnt field in the TX BD properly The bd_cnt field in the TX BD specifies the total number of BDs for the TX packet. The bd_cnt field has 5 bits and the maximum number supported is 32 with the value 0. CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB fragments can approach or exceed the maximum supported by the chip. Add a macro to properly mask the bd_cnt field so that the value 32 will be properly masked and set to 0 in the bd_cnd field. Without this patch, the out-of-range bd_cnt value will corrupt the TX BD and may cause TX timeout. The next patch will check for values exceeding 32.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-80825", "url": "https://ubuntu.com/security/CVE-2026-80825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extra_tx_headroom, but forwarded frames are sent through ieee80211_8023_xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel: skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path. The same bug was fixed on mt7921 by commit 98c4d0abf5c4 (\"mt76: mt7921: don't assume adequate headroom for SDIO headers\"), but mt7925 was copied from mt7921 without the fix. Add the same guard here.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80835", "url": "https://ubuntu.com/security/CVE-2026-80835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Remove crypto_rng interface qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the \"rng\" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80922", "url": "https://ubuntu.com/security/CVE-2026-80922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Allow zero as a random number Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80837", "url": "https://ubuntu.com/security/CVE-2026-80837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't queue packet path object notifications All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply. nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting packet, holding no mutex. Since commit 67cc570edaa0 (\"netfilter: nf_tables: coalesce multiple notifications into one skbuff\") that notification is no longer sent immediately. __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with commit_mutex held. Sending packets through a chain that references a depleted quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been freed: BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by task 77: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain Freed by task 79: nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg The buggy address belongs to the cache skbuff_head_cache of size 232 Queueing from the packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does. The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are still coalesced.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80838", "url": "https://ubuntu.com/security/CVE-2026-80838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: keep the last remote linked during FDB flush A non-nexthop FDB entry is expected to have at least one remote while it remains reachable through the FDB hash table. A filtered bulk flush violates this invariant when every remote matches: It unlinks the last remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush() to destroy the parent FDB entry. An RCU reader can find the parent during this interval. first_remote_rcu() then applies list_entry_rcu() to the empty list head, producing an invalid remote pointer that the receive learning path can read from and write to. When a matching remote is the sole remaining remote, leave it linked and ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80839", "url": "https://ubuntu.com/security/CVE-2026-80839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject unrepresentable multicast TVLV offsets The network and transport header fields in struct sk_buff are 16-bit offsets from skb->head, and U16_MAX is reserved as the unset transport header value. batadv_tvlv_call_handler() sets both fields from a received multicast TVLV without checking whether the TVLV end is representable. If the end offset exceeds the field's range, skb_set_transport_header() truncates it so that the transport header precedes the network header. The negative difference is then returned by skb_network_header_len() as a large u32. batadv_mcast_forw_packet() consequently accepts an oversized multicast tracker and accesses memory beyond the skb data. Add skb_set_transport_header_careful(), an offset-aware counterpart to skb_reset_transport_header_careful(), which validates the final head-relative offset before assigning it. Use the new helper in batadv_tvlv_call_handler() and reject unrepresentable TVLVs before setting the network header.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80849", "url": "https://ubuntu.com/security/CVE-2026-80849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of current_key on reconnect to another peer tcp_inbound_ao_hash() is called before bh_lock_sock_nested() is taken, with only rcu_read_lock() held. On the fast path for established sockets, if the rnext_keyid sent by the peer differs from current_key->sndid, the key the peer asked for is looked up and stored in current_key. The lookup is inside the RCU read side, but current_key outlives it. When the socket is disconnected and connect() is called again for another peer, tcp_ao_connect_init() unlinks every key that does not match the new peer and frees it with call_rcu(). If current_key points at such a key, it is cleared to NULL. The fast path reads sk_state only once on entry, so a softirq that got into it while the socket was still established can update current_key after that loop has already run. The update is inside the RCU read side, so it comes before the call_rcu() callback, and once the callback frees the key, current_key is left pointing at freed memory. The next transmission picks that pointer up in tcp_get_current_key(). tcp_ao_transmit_skb() then reads the traffic key from the freed object, which is the use-after-free. Wait for one grace period before unlinking, and only if a key is going to be removed. By the time tcp_connect() runs the socket is already in TCP_SYN_SENT, and TCP_AO_ESTABLISHED does not contain TCPF_SYN_SENT, so a softirq entering after the wait cannot reach the fast path, and the ones already in it have finished. The existing NULL handling in the loop is then enough.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80850", "url": "https://ubuntu.com/security/CVE-2026-80850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix AO info use-after-free in tcp_ao_connect_init() tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling tcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that a key matches the peer and the bound device's current L3 master. tcp_ao_connect_init() later resolves the L3 master again and removes keys which do not match it. The socket lock does not stabilize the bound device's VRF membership. Detaching the device from its VRF between the initial validation and the L3-master calculation in tcp_ao_connect_init() can therefore make the validation succeed while initialization observes the default L3 domain and removes the only key. The subsequent AO lookup then fails, so the no-key path clears tp->ao_info and frees it directly. The receive path can find the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. A reader which loaded the old pointer can thus continue into tcp_inbound_ao_hash() after the direct free. The issue was found during a static audit of TCP-AO object lifetime. An unprivileged reproducer in self-created user and network namespaces raced connect() with detaching a veth from its VRF while sending TCP-AO segments. It triggered the same KASAN report on two fresh boots: BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232 Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0 Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640 Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720 The bad address is 40 bytes inside the freed 128-byte object, matching the tcp_ao_info counters.key_not_found field. The two runs used 1000 attempts each, reached the no-key path 366 and 411 times, and produced one and two KASAN reports respectively. With this change, the same reproducer reached the no-key path 366 times in 1000 attempts without a KASAN report or oops. Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info, updates the socket memory and static-key accounting, and defers the free until after an RCU grace period. Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race makes the no-key state reachable during normal operation, so it is a handled condition rather than an impossible assertion. On panic_on_warn kernels the WARN would turn this handled race into a kernel panic.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80851", "url": "https://ubuntu.com/security/CVE-2026-80851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: serialize PDP context updates PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80774", "url": "https://ubuntu.com/security/CVE-2026-80774", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80755", "url": "https://ubuntu.com/security/CVE-2026-80755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject a permission value exceeding the class permission count perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. [PM: tweak comment for line length]", "cve_priority": "low", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80864", "url": "https://ubuntu.com/security/CVE-2026-80864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS). Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths. Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80771", "url": "https://ubuntu.com/security/CVE-2026-80771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: register input device after capabilities are set input_register_device() exposes the device to userspace immediately. In joycon_input_create() it was called before joycon_config_rumble() configures the FF_RUMBLE capability and the memless force-feedback device, so a concurrent EVIOCSFF could dereference a NULL dev->ff. Registering early also means the initial udev event lacks button and axis information, which can make input managers ignore the device. Move input_register_device() to the end of joycon_input_create(), after all capabilities, the IMU input device and the force-feedback callbacks have been configured.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2025-40074", "url": "https://ubuntu.com/security/CVE-2025-40074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: start using dst_dev_rcu() Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF. Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().", "cve_priority": "high", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-80820", "url": "https://ubuntu.com/security/CVE-2026-80820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't livelock in scrub on a circular unlinked list LOLLM points out that online fsck can livelock if an unlinked inode list contains a loop. Use a bitmap to detect cycles.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74653", "url": "https://ubuntu.com/security/CVE-2026-74653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 (\"serial: 8250_dw: Avoid \"too much work\" from bogus rx timeout interrupt\") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80815", "url": "https://ubuntu.com/security/CVE-2026-80815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Use a private URB for the notification endpoint scarlett2_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the \"already in use\" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmd_done is left zeroed because it is initialised past that check and nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1 and wait_for_completion_timeout() would crash adding to the zeroed wait.head. Use a separate URB in scarlett2_data, as done for FCP, and initialise cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB in snd_usb_mixer_free() and resubmitting it in snd_usb_mixer_activate(), so scarlett2 must now do both: add scarlett2_cleanup_urb(), called from private_free and private_suspend, and a private_resume callback to re-establish the URB after resume. scarlett2_init_notify() is reached from there, and the URB kill path in scarlett2_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Also free the URB if the transfer buffer allocation fails, and both if usb_submit_urb() fails. Move scarlett2_init_notify() up next to scarlett2_cleanup_urb() so scarlett2_init_private() can reference it without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80727", "url": "https://ubuntu.com/security/CVE-2026-80727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mce: Set up the polling timer before CMCI discovery I hit the following on one of my machines: mce: CPU0 BANK15 CMCI inherited storm ------------[ cut here ]------------ ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0 WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY RIP: 0010:debug_object_assert_init+0x18f/0x230 Call Trace: __mod_timer mce_timer_kick cmci_discover intel_init_cmci mce_intel_feature_init mcheck_cpu_init identify_cpu identify_boot_cpu arch_cpu_finalize_init start_kernel A second splat follows right after, from timer_setup() finding that same timer already queued: ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10 This is happening because CMCI storm detection is trying to modify the timer before latter was properly set up. Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(), and depends on neither the generic nor the vendor init. [ bp: Massage commit message. ]", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74602", "url": "https://ubuntu.com/security/CVE-2026-74602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74684", "url": "https://ubuntu.com/security/CVE-2026-74684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() The commit 4f61f133f354 (\"net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null\") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74483", "url": "https://ubuntu.com/security/CVE-2026-74483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't leak the user namespace when the mount fails bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80556", "url": "https://ubuntu.com/security/CVE-2026-80556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80576", "url": "https://ubuntu.com/security/CVE-2026-80576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject oversized IBs with per-ring packet limits On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74590", "url": "https://ubuntu.com/security/CVE-2026-74590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions The BPF verifier and the dynptr abstraction ensure that the memory space referenced by a dynptr remains valid. They do not, however, provide any guarantee that the contents of the memory are stable. kfuncs are expected to remain memory-safe even if concurrent modifications occur. bpf_get_fsverity_digest() didn't follow that: it could crash if arg->digest_size was concurrently modified. Fix that by using the known-good value hash_alg->digest_size instead. Also widen 'dynptr_sz' and 'out_digest_sz' to u64 to match the return type of __bpf_dynptr_size(). It doesn't appear that it can actually be more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes file-based pointers), but the correct type might as well be used.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74592", "url": "https://ubuntu.com/security/CVE-2026-74592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Instantiate file_truncate and path_truncate hooks Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74618", "url": "https://ubuntu.com/security/CVE-2026-74618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen(\"binfmt_misc\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74634", "url": "https://ubuntu.com/security/CVE-2026-74634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Prevent subbuf order change when resizing is disabled Because ring_buffer_subbuf_order_set() frees buffer pages, we can't allow it when resizing is disabled. A non-consuming reader is at risk of use-after-free (rb_advance_iter()). Return -EBUSY on resize_disabled, matching ring_buffer_resize() behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-64017", "url": "https://ubuntu.com/security/CVE-2026-64017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: pop cached request if it is usable When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use. Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway. The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-74677", "url": "https://ubuntu.com/security/CVE-2026-74677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: \telse \t\tschedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74710", "url": "https://ubuntu.com/security/CVE-2026-74710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: require at least 16 bytes of TX metadata AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74440", "url": "https://ubuntu.com/security/CVE-2026-74440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Wait on external BO kernel fences in exec IOCTL Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-80704", "url": "https://ubuntu.com/security/CVE-2026-80704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80711", "url": "https://ubuntu.com/security/CVE-2026-80711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74484", "url": "https://ubuntu.com/security/CVE-2026-74484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74500", "url": "https://ubuntu.com/security/CVE-2026-74500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix stack info leak in RME Digiface status snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: \tbuf = kmemdup(data, size, GFP_KERNEL); \terr = usb_control_msg(dev, pipe, request, requesttype, \t\t\t value, index, buf, size, timeout); \tmemcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74535", "url": "https://ubuntu.com/security/CVE-2026-74535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: avoid deadlocks in iso_sock_timeout iso_sock_timeout() takes lock_sock, so sync disabling the timer while holding that lock may deadlock. iso_sock_timeout() may also run concurrently with iso_conn_del(), which leads to UAF [Task 1] [Task hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del `------------> iso_conn_put caller frees hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL; /* UAF */ Fix the deadlock by removing the disable from the lock_sock sections. Move the timer from iso_conn to iso_pinfo to decouple it from iso_conn which may need to be freed in lock_sock section. Convert some of the clear_timer to disable_timer.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74536", "url": "https://ubuntu.com/security/CVE-2026-74536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix leaking sk after socket release iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80694", "url": "https://ubuntu.com/security/CVE-2026-80694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74543", "url": "https://ubuntu.com/security/CVE-2026-74543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: \tif (utn->work_pending) \t\treturn; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm \"syz-executor\", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80695", "url": "https://ubuntu.com/security/CVE-2026-80695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74565", "url": "https://ubuntu.com/security/CVE-2026-74565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: make nft_object rhltable per table The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup().", "cve_priority": "high", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-72111", "url": "https://ubuntu.com/security/CVE-2026-72111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reset register bounds before narrowing retval range in check_mem_access() When the BPF verifier processes a context load of an LSM hook return value, it calls __mark_reg_s32_range() to narrow the register to the hook's valid range. However, __mark_reg_s32_range() intersects the new range with the register's existing bounds using max_t()/min_t() rather than replacing them. If the destination register carries stale bounds from a prior instruction (e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than reality. The verifier then believes it knows the register's exact value, while at runtime the actual hook return value is loaded, creating a verifier/runtime mismatch that can be used to bypass BPF memory safety checks. The else branch already calls mark_reg_unknown() to reset register state before any narrowing. Apply the same reset in the is_retval path so stale bounds are cleared before __mark_reg_s32_range() intersects.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80852", "url": "https://ubuntu.com/security/CVE-2026-80852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: device: fix out-of-bounds write in tls_append_frag() Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: worker_thread (kernel/workqueue.c:3405 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": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80762", "url": "https://ubuntu.com/security/CVE-2026-80762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix accept list UAF during suspend hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait. The following interleaving causes the use-after-free: hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next KASAN reported: BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80780", "url": "https://ubuntu.com/security/CVE-2026-80780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from \tlist_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80770", "url": "https://ubuntu.com/security/CVE-2026-80770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: stop device IO before hid_hw_stop on probe failure nintendo_hid_probe() calls hid_device_io_start() before joycon_init() and joycon_leds_create(). If either fails, the error path jumps to err_close which calls hid_hw_close()/hid_hw_stop() without first calling hid_device_io_stop(). hid_hw_stop() does not stop device IO, so hid_input_report() may still run and access driver data that is being torn down, resulting in a use-after-free. Add an err_io_stop label that calls hid_device_io_stop() before hid_hw_close(), and point the two post-io_start error paths at it.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64070", "url": "https://ubuntu.com/security/CVE-2026-64070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/hv-gpci: fix preempt count leak in sysfs show paths Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb) (which calls preempt_disable()) but only call the matching put_cpu_var() on the error path under the 'out:' label. Every successful read leaks one preempt_disable(): processor_bus_topology_show() processor_config_show() affinity_domain_via_virtual_processor_show() affinity_domain_via_domain_show() (affinity_domain_via_partition_show() was already correct.) On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandler_disabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in call_usermodehelper_exec -> wait_for_completion_state -> schedule: BUG: scheduling while atomic: //0x00000004 ... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 Add an out_success label that calls put_cpu_var() before returning the byte count, mirroring affinity_domain_via_partition_show().", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64082", "url": "https://ubuntu.com/security/CVE-2026-64082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Fix register corruption from uninitialized cregs on error compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's pt_regs, corrupting its register state and potentially leaking kernel stack contents. compat_restore_sigcontext() has the same issue: it calls cregs_to_regs() even when __copy_from_user() fails, leading to the same corruption of the signal-returning task's register state on error. Only call cregs_to_regs() when the user copy succeeds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-45963", "url": "https://ubuntu.com/security/CVE-2026-45963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: nau8821: Cancel delayed work on component remove Attempting to unload the driver while a jack detection work is pending would likely crash the kernel when it is eventually scheduled for execution: [ 1984.896308] BUG: unable to handle page fault for address: ffffffffc10c2a20 [...] [ 1984.896388] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 1984.896396] Workqueue: events nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0 [...] [ 1984.896504] Call Trace: [ 1984.896511] [ 1984.896524] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ? srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 Cancel unscheduled jdet_work or wait for its execution to finish before the component driver gets removed.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-40168", "url": "https://ubuntu.com/security/CVE-2025-40168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller.", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40139", "url": "https://ubuntu.com/security/CVE-2025-40139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set(). smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname(). Note that the returned value of smc_clc_prfx_set() is not used in the caller. While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40064", "url": "https://ubuntu.com/security/CVE-2025-40064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Fix use-after-free in __pnet_find_base_ndev(). syzbot reported use-after-free of net_device in __pnet_find_base_ndev(), which was called during connect(). [0] smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened at __pnet_find_base_ndev() when the dev is first used. This means dev had already been freed before acquiring RTNL in pnet_find_base_ndev(). While dev is going away, dst->dev could be swapped with blackhole_netdev, and the dev's refcnt by dst will be released. We must hold dev's refcnt before calling smc_pnet_find_ism_resource(). Also, smc_pnet_find_roce_resource() has the same problem. Let's use __sk_dst_get() and dst_dev_rcu() in the two functions. [0]: BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: dump_stack_lvl+0x189/0x250 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 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff 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 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39833", "url": "https://ubuntu.com/security/CVE-2025-39833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix warning when deleting uninitialized timer With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat: [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10 [ 250.242058] ? __timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update.", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-38237", "url": "https://ubuntu.com/security/CVE-2025-38237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() In fimc_is_hw_change_mode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready. Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling.", "cve_priority": "medium", "cve_public_date": "2025-07-08 08:15:00 UTC" }, { "cve": "CVE-2025-38206", "url": "https://ubuntu.com/security/CVE-2025-38206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix double free in delayed_free The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it.", "cve_priority": "low", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38203", "url": "https://ubuntu.com/security/CVE-2025-38203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix null-ptr-deref in jfs_ioc_trim [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program.", "cve_priority": "low", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-22104", "url": "https://ubuntu.com/security/CVE-2025-22104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 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 lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80763", "url": "https://ubuntu.com/security/CVE-2026-80763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate LE Set CIG Parameters response The Command Complete dispatch validates only the fixed part of the LE Set CIG Parameters response. After that part is pulled from the skb, hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the trailing handle array. Matching num_handles against the command's num_cis does not guarantee that the response contains the advertised handles. A truncated response from a malfunctioning controller can therefore make the handler read beyond the skb data. Validate that the remaining skb data contains all advertised handles. Include this in the existing response validation so malformed responses also follow the established CIG failure handling.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80764", "url": "https://ubuntu.com/security/CVE-2026-80764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix LE list UAF on reset hci_cc_reset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them. This permits the reset completion and a debugfs read to interleave as follows: hci_rx_work debugfs reader ----------- -------------- lock hdev->lock fetch current entry list_del(entry) kfree(entry) read entry fields The reader then dereferences a freed list entry and may follow its stale next pointer. KASAN reported: BUG: KASAN: slab-use-after-free in white_list_show+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95 Call Trace: white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 Allocated by task 91: hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Freed by task 90: kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80772", "url": "https://ubuntu.com/security/CVE-2026-80772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: \tif (size >= 12) /* make sure it contains the input report */ \t\tjoycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the \"(IMU)\" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: \tif (size < sizeof(struct joycon_input_report) || \t data[0] != JC_INPUT_SUBCMD_REPLY) \t\tbreak; Use the same sizeof(struct joycon_input_report) bound here.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80784", "url": "https://ubuntu.com/security/CVE-2026-80784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix memory leak from alloc-during-teardown race mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket teardown, dropping the lock between the two. A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcp_token_get_sock() and, in mptcp_pm_nl_announce_doit(), calls mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which invokes mptcp_destroy_common() without dropping the sock refcount, before the handler completes. If the lock acquisitions interleave such that mptcp_pm_destroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and mptcp_pm_addr_entry objects (from mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent ANNOUNCE + close load against the userspace PM. Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcp_pm_destroy() frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the later alloc observes the bit and refuses. Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74509", "url": "https://ubuntu.com/security/CVE-2026-74509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix advertising data UAFs hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response. An advertising termination event can therefore interleave as follows: hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false KASAN reported: BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller. Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80581", "url": "https://ubuntu.com/security/CVE-2026-80581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80791", "url": "https://ubuntu.com/security/CVE-2026-80791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: zero the AUTH_RECEIVE response buffer nvmet_execute_auth_receive() allocates the response buffer with kmalloc() sized by the host-supplied AUTH_RECEIVE allocation length, but the DH-HMAC-CHAP builders write only a fixed-size message into it. The full allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a remote initiator receives the bytes past the built message -- up to nearly a page of uninitialized slab -- during the pre-authentication handshake. Allocate the buffer with kzalloc() so the unwritten tail is zeroed before it is sent; conforming responses are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80572", "url": "https://ubuntu.com/security/CVE-2026-80572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: byd - synchronize timer deletion before freeing private data byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80551", "url": "https://ubuntu.com/security/CVE-2026-80551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure first IDAW remains constant The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_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. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. 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, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74655", "url": "https://ubuntu.com/security/CVE-2026-74655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: fix TX DMA buffer flush When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-74601", "url": "https://ubuntu.com/security/CVE-2026-74601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Use current_context for safe per-CPU buffer swap The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74628", "url": "https://ubuntu.com/security/CVE-2026-74628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free of the socket by its timers The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74736", "url": "https://ubuntu.com/security/CVE-2026-74736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74737", "url": "https://ubuntu.com/security/CVE-2026-74737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74739", "url": "https://ubuntu.com/security/CVE-2026-74739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74740", "url": "https://ubuntu.com/security/CVE-2026-74740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80742", "url": "https://ubuntu.com/security/CVE-2026-80742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't send zero-byte data in tpacket_snd(). syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f (\"net/af_packet: check len when min_header_len equals to 0\") and in packet_sendmsg_spkt() via commit 6a341729fb31 (\"af_packet: Don't send zero-byte data in packet_sendmsg_spkt().\"). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd().", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80743", "url": "https://ubuntu.com/security/CVE-2026-80743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80904", "url": "https://ubuntu.com/security/CVE-2026-80904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: Fail tls_sw_splice_read() after a failed async decrypt When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80906", "url": "https://ubuntu.com/security/CVE-2026-80906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: packet: fix wrong transport_header when sending VLAN-tagged frame In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to the outer VLAN EtherType (e.g. ETH_P_8021Q), while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74744", "url": "https://ubuntu.com/security/CVE-2026-74744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74746", "url": "https://ubuntu.com/security/CVE-2026-74746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: publish GC-visible tuple last nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80744", "url": "https://ubuntu.com/security/CVE-2026-80744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug. Trace for example: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nf_tables transaction processing: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Change the condition to WARN_ON_ONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74748", "url": "https://ubuntu.com/security/CVE-2026-74748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix refcount race between list:set GC and swap __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74607", "url": "https://ubuntu.com/security/CVE-2026-74607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74599", "url": "https://ubuntu.com/security/CVE-2026-74599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (\"mm/vmalloc: add interfaces to free unmapped page table\"), so we target this in the Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74672", "url": "https://ubuntu.com/security/CVE-2026-74672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Patch series \"mm: fix UAF caused by race between ptdump and vmap pgtable freeing\", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra ---truncated---", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74450", "url": "https://ubuntu.com/security/CVE-2026-74450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74474", "url": "https://ubuntu.com/security/CVE-2026-74474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() for transmit path header pulls In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74487", "url": "https://ubuntu.com/security/CVE-2026-74487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access when removing an entry Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 (\"binfmt_misc: restore write access before closing files opened by open_exec()\") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74476", "url": "https://ubuntu.com/security/CVE-2026-74476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: convert frag_list skbs before running XDP A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74479", "url": "https://ubuntu.com/security/CVE-2026-74479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix proc entry use-after-free pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74494", "url": "https://ubuntu.com/security/CVE-2026-74494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject repeated SMB2 NEGOTIATE requests Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80715", "url": "https://ubuntu.com/security/CVE-2026-80715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80526", "url": "https://ubuntu.com/security/CVE-2026-80526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2562: Validate values for volume writes tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80686", "url": "https://ubuntu.com/security/CVE-2026-80686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-80527", "url": "https://ubuntu.com/security/CVE-2026-80527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80528", "url": "https://ubuntu.com/security/CVE-2026-80528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: avoid fs reclaim while using current->journal_info handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80529", "url": "https://ubuntu.com/security/CVE-2026-80529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't swallow dquot recovery verification errors xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80534", "url": "https://ubuntu.com/security/CVE-2026-80534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80539", "url": "https://ubuntu.com/security/CVE-2026-80539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: disallow multiple FENCE chunks in one submit amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc (\"drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit\") did for p->bo_list. (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80540", "url": "https://ubuntu.com/security/CVE-2026-80540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD decode image min size calculation This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80907", "url": "https://ubuntu.com/security/CVE-2026-80907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD dpb min size calculation for H264 This should use actual number of references from the decode message, instead of maximum derived from level. (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80908", "url": "https://ubuntu.com/security/CVE-2026-80908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reject UVD message with dimensions above 4096 Fixes potential overflow in DPB size calculations. (cherry picked from commit 05e1387d151f71569fbe122d2c89f9db0c21dc10)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80541", "url": "https://ubuntu.com/security/CVE-2026-80541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate GEM_CREATE domain combinations AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80909", "url": "https://ubuntu.com/security/CVE-2026-80909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reject UVD message with invalid number of h265 refs Same change as for h264, avoids overflow later when calculating min dpb size. (cherry picked from commit a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80549", "url": "https://ubuntu.com/security/CVE-2026-80549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Move cp cleanup out of not operational The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80550", "url": "https://ubuntu.com/security/CVE-2026-80550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Fix out of bounds check on CCW array The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is \"do..while (count < 257)\", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80554", "url": "https://ubuntu.com/security/CVE-2026-80554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Limit the number of channel program segments The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80558", "url": "https://ubuntu.com/security/CVE-2026-80558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80559", "url": "https://ubuntu.com/security/CVE-2026-80559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: sur40 - fix input device registration ordering In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80560", "url": "https://ubuntu.com/security/CVE-2026-80560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: signal: do not restore privileged SR bits on sigreturn restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80561", "url": "https://ubuntu.com/security/CVE-2026-80561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix multiple unsafe decodes in decode_locker() decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80565", "url": "https://ubuntu.com/security/CVE-2026-80565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix error path in devm_qce_register_algs If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80566", "url": "https://ubuntu.com/security/CVE-2026-80566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: hynitron_cstxxx - validate touch count and finger IDs The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80567", "url": "https://ubuntu.com/security/CVE-2026-80567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80568", "url": "https://ubuntu.com/security/CVE-2026-80568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - block s_input when F54 queue is busy Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80569", "url": "https://ubuntu.com/security/CVE-2026-80569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): \treport_size = rmi_f54_get_report_size(f54); \t... \tfor (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { \t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i); \t\t... \t\trmi_read_block(.., f54->report_data + i, size); \t} report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80570", "url": "https://ubuntu.com/security/CVE-2026-80570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80573", "url": "https://ubuntu.com/security/CVE-2026-80573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - validate input packet lengths iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80752", "url": "https://ubuntu.com/security/CVE-2026-80752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: psxpad-spi - set driver data before use psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80574", "url": "https://ubuntu.com/security/CVE-2026-80574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1].", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80754", "url": "https://ubuntu.com/security/CVE-2026-80754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix F55 transmitter electrode count typo During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80578", "url": "https://ubuntu.com/security/CVE-2026-80578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80910", "url": "https://ubuntu.com/security/CVE-2026-80910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses EAR SPKR PA Gain\" and the four \"WSA RX* Mux\" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80911", "url": "https://ubuntu.com/security/CVE-2026-80911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80584", "url": "https://ubuntu.com/security/CVE-2026-80584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: validate user buffer length in SNMP and ARP query ioctls qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80585", "url": "https://ubuntu.com/security/CVE-2026-80585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fastopen: only mark MPTFO subflows with SYN data Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really \"doing TFO\".", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80586", "url": "https://ubuntu.com/security/CVE-2026-80586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80756", "url": "https://ubuntu.com/security/CVE-2026-80756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: do not cancel a policy conversion that never started sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80757", "url": "https://ubuntu.com/security/CVE-2026-80757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject a class permission count below its inherited common security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80913", "url": "https://ubuntu.com/security/CVE-2026-80913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: require every boolean value to be defined p_bools.nprim comes from the policy image independently of how many booleans follow it, and cond_index_bool() fills bool_val_to_struct[] at value - 1, so a count larger than the values present leaves NULL entries. Every user of that array then walks it by index and dereferences each entry: cond_evaluate_expr() on the access-vector path, security_get_bools() and security_get_bool_value() behind selinuxfs, and security_set_bools(). A sparse class value is absorbed by policydb_class_isvalid() and its siblings; booleans have no such predicate, and no consumer that could use one. Reject a boolean value that no boolean defines, once, where the array is built. Conforming policies define every boolean they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2025-40054", "url": "https://ubuntu.com/security/CVE-2025-40054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF issue in f2fs_merge_page_bio() As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list \t\t\t\t\t\twrite \t\t\t\t\t\t- f2fs_write_begin \t\t\t\t\t\t: write page #1 \t\t\t\t\t\t - f2fs_folio_wait_writeback \t\t\t\t\t\t - f2fs_submit_merged_ipu_write \t\t\t\t\t\t - f2fs_submit_write_bio \t\t\t\t\t\t : submit bio which inclues page #1 and #2 \t\t\t\t\t\tsoftware IRQ \t\t\t\t\t\t- f2fs_write_end_io \t\t\t\t\t\t - fscrypt_free_bounce_page \t\t\t\t\t\t : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\ -c \"pwrite 0 32k\" -c \"fdatasync\" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\ -c \"pwrite 0 32k\" -c \"fdatasync\" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-80589", "url": "https://ubuntu.com/security/CVE-2026-80589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: stop the timeout timer when releasing a never added disk disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d (\"block: simplify disk shutdown\") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74585", "url": "https://ubuntu.com/security/CVE-2026-74585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound the DROM dual link port number before indexing sw->ports tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74586", "url": "https://ubuntu.com/security/CVE-2026-74586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear new_transport when removing a peer sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74587", "url": "https://ubuntu.com/security/CVE-2026-74587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix use-after-free of cached ASCONF chunk addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74588", "url": "https://ubuntu.com/security/CVE-2026-74588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: \tif (chunk->tsn_gap_acked) { \t\tlist_move_tail(&chunk->transmitted_list, \t\t\t &transport->transmitted); \t\tcontinue; \t} The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches \ttchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74589", "url": "https://ubuntu.com/security/CVE-2026-74589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix sk_redir use-after-free in send verdict sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes remains nonzero release_sock(sk) lock_sock(sk) apply_bytes reaches zero psock->sk_redir = NULL release_sock(sk) tcp_bpf_sendmsg_redir(sk_redir) sock_put(sk_redir) tcp_bpf_sendmsg_redir(sk_redir) The final sock_put() can free sk_redir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 85: sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 Freed by task 0: __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: __sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->sk_redir, and drop it after tcp_bpf_sendmsg_redir() returns. This keeps each unlocked use independent of cached-verdict ownership.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74594", "url": "https://ubuntu.com/security/CVE-2026-74594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/psi: Shut down rtpoll_timer in psi_cgroup_free() psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath and can race psi_trigger_destroy() taking down the last rtpoll trigger under rtpoll_trigger_lock: psi_schedule_rtpoll_work() psi_trigger_destroy() rcu_read_lock(); task = rcu_dereference(rtpoll_task); rcu_assign_pointer(rtpoll_task, NULL); timer_delete(&rtpoll_timer); mod_timer(&rtpoll_timer, ...); rcu_read_unlock(); synchronize_rcu(); kthread_stop(task_to_destroy); The group can then be freed with the re-armed timer still pending, and poll_timer_fn() runs on freed memory. 461daba06bdc (\"psi: eliminate kthread_worker from psi trigger scheduling mechanism\") deleted the timer synchronously after the synchronize_rcu(), which prevented this but raced trigger creation instead: the deletion could cancel the timer that a new trigger set armed during the grace period and, as creation also reinitialized the timer at the time, corrupt it. 8f91efd870ea (\"psi: Fix race between psi_trigger_create/destroy\") moved the initialization into group_init() and the deletion into the locked section, trading the creation races for the window above. Neither placement in the destruction path works. A pending timer firing while the group is alive is harmless though. poll_timer_fn() just wakes the rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it by then. timer_shutdown_sync() because the timer is never armed again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74595", "url": "https://ubuntu.com/security/CVE-2026-74595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74597", "url": "https://ubuntu.com/security/CVE-2026-74597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip6ip6_err() ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74598", "url": "https://ubuntu.com/security/CVE-2026-74598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74603", "url": "https://ubuntu.com/security/CVE-2026-74603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix board ID over-read The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74604", "url": "https://ubuntu.com/security/CVE-2026-74604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\" Revert commit 030a48b0f6ce (\"thermal/drivers/hwmon: Cleanup coding style a bit\") that introduced a use-after-free into the error path of thermal_add_hwmon_sysfs() by removing a valid check from it.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74606", "url": "https://ubuntu.com/security/CVE-2026-74606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec() eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74608", "url": "https://ubuntu.com/security/CVE-2026-74608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_try_adding_channels() cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory. Increment weight_fulfilled before dropping the temporary reference, keeping iface alive for the final access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74609", "url": "https://ubuntu.com/security/CVE-2026-74609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: \tstruct tipc_link *l = le->link;\t\t/* unlocked */ \tif (!l) \t\treturn; \ttipc_node_write_lock(n); \tif (!tipc_link_is_establishing(l)) {\t/* deref l */ \t... \t\ttipc_link_reset(l);\t\t/* write into l */ \tif (delete) { \t\tkfree(l); \t\tle->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74610", "url": "https://ubuntu.com/security/CVE-2026-74610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: don't leave a full plaintext sk_msg ring unpushed When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the \"tls\" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74580", "url": "https://ubuntu.com/security/CVE-2026-74580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: reset the vring metadata cache on vring reconfiguration vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: \tif (vhost_vq_meta_fetch(vq, addr, len, type)) \t\treturn true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as \tmap->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74612", "url": "https://ubuntu.com/security/CVE-2026-74612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix skb length accounting after XDP frag adjustment veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT(). Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74613", "url": "https://ubuntu.com/security/CVE-2026-74613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: avoid refilling the RX queue after teardown Commit b917507e5ad9 (\"vsock/virtio: stop workers during the .remove()\") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. BUG: KASAN: slab-use-after-free in virtqueue_add_sgs Read of size 4 by task kworker/0:1 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796) virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332) virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701) process_one_work (kernel/workqueue.c:3314) worker_thread (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 141: kfree (mm/slub.c:6566) vp_del_vq (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912) virtio_device_freeze (drivers/virtio/virtio.c:658) virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601) pci_pm_freeze (drivers/pci/pci-driver.c:1098) device_suspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: panic_on_warn set ... Jump to a no-refill exit when rx_run is clear, leaving the normal exit to replenish a running queue.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74614", "url": "https://ubuntu.com/security/CVE-2026-74614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: read virtqueues under worker locks Commit bd50c5dc182b (\"vsock/virtio: add support for device suspend/resume\") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue. Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74615", "url": "https://ubuntu.com/security/CVE-2026-74615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: \tif (conf.age_interval != vxlan->cfg.age_interval) \t\tmod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74616", "url": "https://ubuntu.com/security/CVE-2026-74616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: reject clones that overrun skb_shared_info tailroom xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74619", "url": "https://ubuntu.com/security/CVE-2026-74619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(\"overlay\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74620", "url": "https://ubuntu.com/security/CVE-2026-74620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: \tif (!opcode) \t\tret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b (\"net: sched: refactor reinsert action\"), after both goto-chain guards were written: commit 9469f375ab09 (\"net/sched: act_gact: disallow 'goto chain' on fallback control action\") and commit c08f5ed5d625 (\"net/sched: act_police: disallow 'goto chain' on fallback control action\"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74621", "url": "https://ubuntu.com/security/CVE-2026-74621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: \tif (family == NFPROTO_IPV4) \t\terr = tcf_ct_ipv4_is_fragment(skb, &frag); \telse \t\terr = tcf_ct_ipv6_is_fragment(skb, &frag); \tif (err || !frag) \t\treturn err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: \terr = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); \tif (err) \t\tgoto out_frag; \t... out_frag: \tif (err != -EINPROGRESS) \t\ttcf_action_inc_drop_qstats(&c->common); \treturn TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with \"action ct\". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74622", "url": "https://ubuntu.com/security/CVE-2026-74622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74623", "url": "https://ubuntu.com/security/CVE-2026-74623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and \"page_pool_release_retry() stalled pool shutdown\" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74624", "url": "https://ubuntu.com/security/CVE-2026-74624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: defer invalid log until after unlock TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74625", "url": "https://ubuntu.com/security/CVE-2026-74625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: release template ct on non-IP path A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74630", "url": "https://ubuntu.com/security/CVE-2026-74630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent in6_dev_get() from resurrecting inet6_dev in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74631", "url": "https://ubuntu.com/security/CVE-2026-74631", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: smc: fix splice entry lifetime imbalance in smc_rx_splice smc_rx_splice() passes pages to splice_to_pipe() before taking the references that cover the lifetime of each splice entry. In the VM-backed RMB path, splice_to_pipe() may drop unqueued entries through smc_rx_spd_release(), while queued entries are released later via the pipe buffer callback. The old post-splice accounting also derives the number of queued VM pages from an offset mutated while building the descriptor, and a multi-page splice pairs one sock_hold() with multiple sock_put() calls. Take the page and socket references for every candidate entry before splice_to_pipe(), and drop the matching private state, page reference, and socket reference from smc_rx_spd_release() for entries that never get queued. This fixes a refcount imbalance that can underflow page refcounts and trigger a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74635", "url": "https://ubuntu.com/security/CVE-2026-74635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_cursor() bit_cursor() fetches the glyph under the cursor with \tc = scr_readw(vc_pos); \tsrc = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c. When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access. BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970 Call Trace: soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 update_region+0x100/0x18c drivers/tty/vt/vt.c:669 vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685 bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata. The fix completes the bounds checking started in commit 18c4ef4e765a (\"fbdev: bitblit: bound-check glyph index in bit_putcs*\"), which missed the cursor path. This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74636", "url": "https://ubuntu.com/security/CVE-2026-74636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74641", "url": "https://ubuntu.com/security/CVE-2026-74641", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: bound the hwdep mmap fault offset snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: \toffset = vmf->pgoff << PAGE_SHIFT; \tvaddr = (char *)(...)->us428ctls_sharedmem + offset; \tpage = virt_to_page(vaddr); \tget_page(page); \tvmf->page = page; \treturn 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page offset above zero resolves to a struct page outside the object, and the handler installs it into the caller's address space read-write; the vma is not marked read-only. The caller picks the page frame with a single mmap() argument and gets read-write access to a page of kernel memory it does not own; an offset that lands in an unpopulated vmemmap region oopses instead. A process that can open the hwdep node of an attached US-X2Y reaches this after loading the FPGA image through the same node; no capability check is involved. On 7.2.0-rc5 (arm64), mmap() with a large offset: Unable to handle kernel paging request at virtual address fffffdffc45d5ac8 pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] Call trace: snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] __do_fault __handle_mm_fault handle_mm_fault el0_da Reject any offset outside the shared region. The pcm hwdep handler in usx2yhwdeppcm.c computes its address the same way and needs the same bound. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80730", "url": "https://ubuntu.com/security/CVE-2026-80730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix crash passing ERR_PTR to kthread_stop() In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that hold an ERR_PTR. rb_threads[] is static, so unassigned slots are NULL. But when kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free. That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall self-test. crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74646", "url": "https://ubuntu.com/security/CVE-2026-74646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74648", "url": "https://ubuntu.com/security/CVE-2026-74648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: validate monitor transmit frame lengths rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated header span.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74649", "url": "https://ubuntu.com/security/CVE-2026-74649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix missing shared-key auth challenge length check The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of an overflow, the driver can write out of bounds. In the case of an underfill, the driver can echo stale buffer memory. The challenge text is defined to be exactly 128 octets, which is already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the element to be exactly that length before use.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74650", "url": "https://ubuntu.com/security/CVE-2026-74650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in WMM_param_handler() WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to join_cmd_hdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer. The remaining caller in rtw_wlan_util.c already guards the handler with \"pIE->length == WLAN_WMM_LEN\". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74651", "url": "https://ubuntu.com/security/CVE-2026-74651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body length. A vendor-specific IE whose length byte is 0 to 5, placed at the end of the buffer, therefore makes these reads run past the end of the IE and past the end of the buffer itself. The buffer holds information elements taken from received management frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which is kmemdup'd to its exact length, so the read can run off the end of the allocation. The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and rtw_get_wps_ie() in this file already reject too-short vendor-specific IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in line with them, and needs a minimum of 6 rather than 4 bytes because of the version word. Add the missing length check.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74654", "url": "https://ubuntu.com/security/CVE-2026-74654", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 (\"serial: 8250_dw: Ensure BUSY is deasserted\") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74656", "url": "https://ubuntu.com/security/CVE-2026-74656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74657", "url": "https://ubuntu.com/security/CVE-2026-74657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74658", "url": "https://ubuntu.com/security/CVE-2026-74658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 (\"futex: Prevent robust futex exit race\"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 (\"futex: Add support for unlocking robust futexes\") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74514", "url": "https://ubuntu.com/security/CVE-2026-74514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix memory accounting for pinned/unpinned pages The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. [borntraeger@linux.ibm.com: Fixed whitespace]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74659", "url": "https://ubuntu.com/security/CVE-2026-74659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with \tsub_tlv = skb_put(skb, sizeof(*sub_tlv)); \tsub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74660", "url": "https://ubuntu.com/security/CVE-2026-74660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74661", "url": "https://ubuntu.com/security/CVE-2026-74661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix netdev use-after-free in beacon worker mac802154_beacon_worker() reads local->beacon_req under RCU and derives the sub-interface from the request, but then drops the RCU read lock and continues to use both sdata and the embedded wpan_dev. mac802154_stop_beacons_locked() cancels only pending beacon work, clears local->beacon_req and frees the request. A beacon worker that is already running can therefore continue after interface teardown and dereference the freed netdev private area. The scan worker already pins the netdev before leaving RCU. Apply the same lifetime rule to the beacon worker: take a netdev reference while the request is still protected by RCU, and release it on all paths that continue after the reference is acquired.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80731", "url": "https://ubuntu.com/security/CVE-2026-80731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74664", "url": "https://ubuntu.com/security/CVE-2026-74664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74667", "url": "https://ubuntu.com/security/CVE-2026-74667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c (\"macsec: do not read an unset MAC header in macsec_encrypt()\"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74669", "url": "https://ubuntu.com/security/CVE-2026-74669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74670", "url": "https://ubuntu.com/security/CVE-2026-74670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74671", "url": "https://ubuntu.com/security/CVE-2026-74671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix out-of-bounds read in xattr_verify() The digest-length check in xattr_verify() mixes int and size_t: \tif (xattr_len - sizeof(xattr_value->type) - hash_start >= \t\t\tiint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns \"1 - 1 - 1\" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74673", "url": "https://ubuntu.com/security/CVE-2026-74673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74675", "url": "https://ubuntu.com/security/CVE-2026-74675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: stabilize tty reference in kbd_keycode with tty_port_tty_get kbd_keycode() reads vc->port.tty without acquiring a tty reference, racing against con_shutdown() which clears port.tty under a different lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference for the duration the tty pointer is needed.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74676", "url": "https://ubuntu.com/security/CVE-2026-74676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74678", "url": "https://ubuntu.com/security/CVE-2026-74678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the \"drop\" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74679", "url": "https://ubuntu.com/security/CVE-2026-74679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Use unsigned int for ndp_index The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74680", "url": "https://ubuntu.com/security/CVE-2026-74680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74682", "url": "https://ubuntu.com/security/CVE-2026-74682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: \tu->packets = urb_packs; \tu->buffer_size = maxsize * u->packets; \tif (fmt->fmt_type == UAC_FORMAT_TYPE_II) \t\tu->packets++; /* for transfer delimiter */ \tu->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: \toffs = 0; \tfor (i = 0; i < urb_ctx->packets; i++) { \t\turb->iso_frame_desc[i].offset = offs; \t\turb->iso_frame_desc[i].length = ep->curpacksize; \t\toffs += ep->curpacksize; \t} \turb->transfer_buffer_length = offs; \turb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74683", "url": "https://ubuntu.com/security/CVE-2026-74683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74688", "url": "https://ubuntu.com/security/CVE-2026-74688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear control chunk transport if it is being removed sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74689", "url": "https://ubuntu.com/security/CVE-2026-74689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/atm: fix slab-out-of-bounds read in vcc_setsockopt() vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80732", "url": "https://ubuntu.com/security/CVE-2026-80732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_sl82c105: fix bridge revision use-after-free pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b (\"PCI: Change all drivers to use pci_device->revision\") replaced a configuration-space read with direct access to the cached revision field, but left that access after pci_dev_put(). The bridge may therefore be freed before its revision is read. Read the revision before dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74691", "url": "https://ubuntu.com/security/CVE-2026-74691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 (\"net: thunderbolt: Enable DMA paths only after rings are enabled\") moved the path enable to the end of tbnet_connected_work() and documented why: \t/* Both logins successful so enable the rings, high-speed DMA \t * paths and start the network device queue. \t * \t * Note we enable the DMA paths last to make sure we have primed \t * the Rx ring before any incoming packets are allowed to \t * arrive. \t */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional \"return 0\". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74692", "url": "https://ubuntu.com/security/CVE-2026-74692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80733", "url": "https://ubuntu.com/security/CVE-2026-80733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE() from sk_mc_loop() sk_mc_loop() can be called for sockets that are neither AF_INET nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet socket over virtual devices such as VRF or ipvlan). In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls through the switch statement and triggers WARN_ON_ONCE(1). Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP options, so loopback should default to true without generating a warning.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74693", "url": "https://ubuntu.com/security/CVE-2026-74693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74694", "url": "https://ubuntu.com/security/CVE-2026-74694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74696", "url": "https://ubuntu.com/security/CVE-2026-74696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74697", "url": "https://ubuntu.com/security/CVE-2026-74697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Disable EOP for TPA on all chips to prevent data corruption EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74700", "url": "https://ubuntu.com/security/CVE-2026-74700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create(\"u32\") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create(\"flower\") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind \"flower\" but tp->ops->kind is \"u32\") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable \"not_lockless\" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74701", "url": "https://ubuntu.com/security/CVE-2026-74701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/openvswitch: check Ethernet header length in key_extract() When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74704", "url": "https://ubuntu.com/security/CVE-2026-74704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74705", "url": "https://ubuntu.com/security/CVE-2026-74705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74714", "url": "https://ubuntu.com/security/CVE-2026-74714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 (\"bpf: tcp: Make sure iter->batch always contains a full bucket snapshot\"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74717", "url": "https://ubuntu.com/security/CVE-2026-74717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74718", "url": "https://ubuntu.com/security/CVE-2026-74718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74583", "url": "https://ubuntu.com/security/CVE-2026-74583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: fix fastmap use-after-free on filter The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74719", "url": "https://ubuntu.com/security/CVE-2026-74719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74720", "url": "https://ubuntu.com/security/CVE-2026-74720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74722", "url": "https://ubuntu.com/security/CVE-2026-74722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74724", "url": "https://ubuntu.com/security/CVE-2026-74724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: avoid out-of-bounds write in ip_vs_nat_icmp Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80739", "url": "https://ubuntu.com/security/CVE-2026-80739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74726", "url": "https://ubuntu.com/security/CVE-2026-74726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) 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) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74730", "url": "https://ubuntu.com/security/CVE-2026-74730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Pin the 'struct nfs_server' during a FREE_STATEID call Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80708", "url": "https://ubuntu.com/security/CVE-2026-80708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74441", "url": "https://ubuntu.com/security/CVE-2026-74441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port().", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-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-80893", "url": "https://ubuntu.com/security/CVE-2026-80893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork() copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages. No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows: offset before=120e00 offset after =120e02 The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it. Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte(). A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80700", "url": "https://ubuntu.com/security/CVE-2026-80700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate external BO copy bounds for both stride paths vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80887", "url": "https://ubuntu.com/security/CVE-2026-80887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: use check_add_overflow for shader size+offset bound vmw_shader_define() validates the user-supplied shader window against its backing buffer with \t(u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18: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-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74445", "url": "https://ubuntu.com/security/CVE-2026-74445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80702", "url": "https://ubuntu.com/security/CVE-2026-80702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74446", "url": "https://ubuntu.com/security/CVE-2026-74446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74448", "url": "https://ubuntu.com/security/CVE-2026-74448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix QID bit leak in pqm_create_queue() When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80703", "url": "https://ubuntu.com/security/CVE-2026-80703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5)", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-74454", "url": "https://ubuntu.com/security/CVE-2026-74454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO.", "cve_priority": "high", "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-80706", "url": "https://ubuntu.com/security/CVE-2026-80706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: softing: fw_parse(): validate firmware record spans fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80707", "url": "https://ubuntu.com/security/CVE-2026-80707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. [mkl: add Message-ID]", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-80678", "url": "https://ubuntu.com/security/CVE-2026-80678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Fix slave registration race and error handling In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80709", "url": "https://ubuntu.com/security/CVE-2026-80709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80710", "url": "https://ubuntu.com/security/CVE-2026-80710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix undersized format-check buffer fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80679", "url": "https://ubuntu.com/security/CVE-2026-80679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80680", "url": "https://ubuntu.com/security/CVE-2026-80680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80890", "url": "https://ubuntu.com/security/CVE-2026-80890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: reject stale cookies with mismatched verification tags sctp_unpack_cookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4. For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent. The broad check lets an expired Action A restart cookie reach sctp_sf_do_dupcook_a(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association. Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74470", "url": "https://ubuntu.com/security/CVE-2026-74470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: \trep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - \t\t\t RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); \tarr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.", "cve_priority": "high", "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-74472", "url": "https://ubuntu.com/security/CVE-2026-74472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the \"->state != UBLK_S_DEV_DEAD\" test that ublk_stop_dev_unlocked() uses as its proxy for \"a disk is attached\", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state.", "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-80681", "url": "https://ubuntu.com/security/CVE-2026-80681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: re-fetch eth header after route_shortcircuit() Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74581", "url": "https://ubuntu.com/security/CVE-2026-74581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: clear suppressed fib6 rule result fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16: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-80714", "url": "https://ubuntu.com/security/CVE-2026-80714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: do not propagate one-packet flag to synced conns Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74501", "url": "https://ubuntu.com/security/CVE-2026-74501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix use-after-free in ump_to_endpoint() create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74502", "url": "https://ubuntu.com/security/CVE-2026-74502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: fix double free of out_cvts on rawmidi error snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80716", "url": "https://ubuntu.com/security/CVE-2026-80716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74510", "url": "https://ubuntu.com/security/CVE-2026-74510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.", "cve_priority": "high", "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-80717", "url": "https://ubuntu.com/security/CVE-2026-80717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate Adaptation Indication parameter length The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80891", "url": "https://ubuntu.com/security/CVE-2026-80891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Validate AIBV and AISB before pinning guest pages The AIBV holds one bit per MSI-X vector for a given function. The size of the bit vector is derived from the NOI and the AIBVO. If the size of the AIBV exceeds a single page boundary, then reject the request as we cannot safely pin the guest AIBV. Similarly reject the request if the AISB address is not 8-byte aligned as the architecture requires doubleword alignment for the summary bit address. Since the AISBO can address up to 64 bits, the size of the AISB can only be 8 bytes for the function. This also ensures the AISB doesn't exceed a single page boundary.", "cve_priority": "high", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80684", "url": "https://ubuntu.com/security/CVE-2026-80684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix NULL dereference on AIBV allocation failure The airq_iv_create() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvm_zpci_set_airq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74515", "url": "https://ubuntu.com/security/CVE-2026-74515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Reject adapter interrupt forwarding if already enabled The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74516", "url": "https://ubuntu.com/security/CVE-2026-74516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a \"safe\" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "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-80718", "url": "https://ubuntu.com/security/CVE-2026-80718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 (\"percpu: make percpu-km set chunk->populated bitmap properly\") introduced the bitmap overflow issue. Later, commit b539b87fed37f (\"percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated\") added pcpu_nr_empty_pop_pages and caused the accounting issue.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80892", "url": "https://ubuntu.com/security/CVE-2026-80892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: cap LZMA stream pool size fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream pool from num_possible_cpus() when the lzma_streams module parameter is unset, then z_erofs_load_lzma_config() preallocates one image-supplied dictionary per stream, accepting dictionaries up to 8 MiB. On high-CPU systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed decoder state until the erofs module is unloaded. Impact: An EROFS image mounted by the system can pin up to 8 MiB of vmalloc memory per LZMA stream, either as intended or unexpectedly. Bound the default stream count by a new CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the worst-case default preallocation is 128 MiB if the number of CPUs is no less than 16 while preserving the existing per-image dictionary limit. An explicit lzma_streams module parameter is still honoured as-is, so administrators who deliberately size the pool are not affected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18: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-74522", "url": "https://ubuntu.com/security/CVE-2026-74522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __close_file_table_ids() A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17: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-80691", "url": "https://ubuntu.com/security/CVE-2026-80691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE In the iblock_execute_pr_out() function, PRO_PREEMPT, PRO_PREEMPT_AND_ABORT, and PRO_RELEASE all perform callback capability checks through ops->pr_clear. The error check allows unimplemented hooks to pass through the gate, resulting dereferencing a NULL function pointer. Check whether the hooks that need to be called are supported.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74531", "url": "https://ubuntu.com/security/CVE-2026-74531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: hold conn reference in abort_conn_sync() There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74532", "url": "https://ubuntu.com/security/CVE-2026-74532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access.", "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-74541", "url": "https://ubuntu.com/security/CVE-2026-74541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: clear iso_data always when detaching conn from hcon When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80722", "url": "https://ubuntu.com/security/CVE-2026-80722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate individual TWT params before driver setup ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. [edit commit message to not overclaim lack of validation nor understate driver impact]", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-74550", "url": "https://ubuntu.com/security/CVE-2026-74550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74551", "url": "https://ubuntu.com/security/CVE-2026-74551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) DMA-align output buffer Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74552", "url": "https://ubuntu.com/security/CVE-2026-74552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74553", "url": "https://ubuntu.com/security/CVE-2026-74553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74555", "url": "https://ubuntu.com/security/CVE-2026-74555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 (\"scsi: libsas: Don't always drain event workqueue for HA resume\") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path.", "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-80901", "url": "https://ubuntu.com/security/CVE-2026-80901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix the checksum validations ip_vs_in_icmp_v6() is missing checksum validation for ICMPv6 packets from clients. In fact, as for TCP/UDP we should validate the checksum for ICMP packets only when we mangle the packets on MASQ or on reply for tunnel. Also, Sashiko points out that handle_response_icmp() being common for IPv4 and IPv6 is missing the pseudo-header calculation while validating ICMPv6 messages from real servers which is a problem if checksum is not validated by the hardware. Fix the problems by creating ip_vs_checksum_common_check() helper and use it for TCP/UDP/ICMP both for IPv4 and IPv6. Rely on the nf_checksum() for validating the ICMP messages but use it also for TCP and UDP. Use correct IP offset for IP_VS_DBG_RL_PKT for TCP/UDP/SCTP. IPVS packets (TCP/UDP/SCTP/ICMP) do not need checksum validation on LOCAL_OUT (local clients or local real servers) and on FORWARD (traffic from servers on LAN). Do it only on LOCAL_IN, in case nf_checksum() is not called on PRE_ROUTING. Also, ip_vs_checksum_complete() can be marked static.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17: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-74572", "url": "https://ubuntu.com/security/CVE-2026-74572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74574", "url": "https://ubuntu.com/security/CVE-2026-74574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-80902", "url": "https://ubuntu.com/security/CVE-2026-80902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA When terminating DMA transfers, active descriptors are not properly reclaimed. Only cyclic descriptors were handled, leaving non-cyclic descriptors and their LLI chains to be permanently leaked. Fix by using vchan_terminate_vdesc() which handles both cyclic and non-cyclic descriptors by adding them to desc_terminated queue for proper cleanup. Add pchan->desc != pchan->done check to prevent double-adding completed descriptors, which would corrupt the list.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74575", "url": "https://ubuntu.com/security/CVE-2026-74575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 (\"thunderbolt: Run tb_xdp_handle_request() in system workqueue\") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18: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-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" } ], "launchpad_bugs_fixed": [ 2171733, 2167919, 2171033, 2170957, 2169943, 2167995, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2170052, 1786013, 2169329, 2131181, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770 ], "changes": [ { "cves": [ { "cve": "CVE-2026-63974", "url": "https://ubuntu.com/security/CVE-2026-63974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2024-50169", "url": "https://ubuntu.com/security/CVE-2024-50169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Update rx_bytes on read_skb() Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt() calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after vsock_transport::read_skb(). While here, also inform the peer that we've freed up space and it has more credit. Failing to update rx_bytes after packet is dequeued leads to a warning on SOCK_STREAM recv(): [ 233.396654] rx_queue is empty, but rx_bytes is non-zero [ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589", "cve_priority": "medium", "cve_public_date": "2024-11-07 10:15:00 UTC" }, { "cve": "CVE-2026-98375", "url": "https://ubuntu.com/security/CVE-2026-98375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.", "cve_priority": "low", "cve_public_date": "2026-10-09 08:16:00 UTC" }, { "cve": "CVE-2026-97567", "url": "https://ubuntu.com/security/CVE-2026-97567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: prevent race between disconnect() and rtx Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93179", "url": "https://ubuntu.com/security/CVE-2026-93179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89527", "url": "https://ubuntu.com/security/CVE-2026-89527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Use svc_xprt_put to free listener on create failure svc_rdma_create() calls kfree(cma_xprt) when svc_rdma_create_listen_id() fails. svc_xprt_init() has already acquired a net namespace reference via get_net_track(); kfree bypasses svc_xprt_free() which releases it. Replace the kfree() with svc_xprt_put() so the kref_init birth reference drops to zero and svc_xprt_free() dispatches svc_rdma_free() to clean up properly. sc_cm_id is still NULL at that point; the preceding patch added the necessary NULL guard in svc_rdma_free(). svc_xprt_free() also drops the module reference via module_put(), but the caller _svc_xprt_create() does the same on xpo_create failure, double-putting the single try_module_get() it acquired. Take a compensating __module_get() before the svc_xprt_put() to keep the count balanced, matching the convention in svc_rdma_accept()'s error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89912", "url": "https://ubuntu.com/security/CVE-2026-89912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2025-38204", "url": "https://ubuntu.com/security/CVE-2025-38204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds read in add_missing_indices stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error.", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-40158", "url": "https://ubuntu.com/security/CVE-2025-40158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: use RCU in ip6_output() Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF. We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2026-93243", "url": "https://ubuntu.com/security/CVE-2026-93243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: properly account locked pages secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit. However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked. A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range. Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process. Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability. A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm. Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass. There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too. Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction. __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc. use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up. test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix. A new test will be sent separately for upstream.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89638", "url": "https://ubuntu.com/security/CVE-2026-89638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode. Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case: \t/* skip mode change if it's just for clearing setuid/setgid */ \tif (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) \t\tattrs->ia_valid &= ~ATTR_MODE; This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway. However, with the \"cifsacl\" or \"modefromsid\" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo(). In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write. This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution. Fix this in two places: 1. cifs_setattr_nounix(): only take the \"skip mode change\" shortcut when the mode is emulated via the DOS read-only attribute (i.e. neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are in effect), so that the cleared mode is propagated to the server in the ACL / POSIX cases. 2. cifs_setattr_unix(): this function is only called when Unix extensions are in effect, so the mode is always stored on the server. Remove the shortcut entirely so that the cleared mode is always pushed.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90146", "url": "https://ubuntu.com/security/CVE-2026-90146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, xdp: move offload check into dev_xdp_install() bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path. dev_xdp_install() is the one place all three paths go through: \"ip link set xdp\" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-97558", "url": "https://ubuntu.com/security/CVE-2026-97558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix cifsFileInfo reference leak in deferred close When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89633", "url": "https://ubuntu.com/security/CVE-2026-89633", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2() coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds: data_area_of_tgt = (char *)&pSMBt->hdr.Protocol + get_unaligned_le16(&pSMBt->t2_rsp.DataOffset); data_area_of_src = (char *)&pSMBs->hdr.Protocol + get_unaligned_le16(&pSMBs->t2_rsp.DataOffset); data_area_of_tgt += total_in_tgt; ... memcpy(data_area_of_tgt, data_area_of_src, total_in_src); A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts. The \"validate target area\" comment present since the function was first written in 2005 was a placeholder that was never implemented. Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-149.149 -proposed tracker (LP: #2171733)", "", " * Incorrect backport of the fix for CVE-2026-63974 to Noble kernel", " (LP: #2167919)", " - SAUCE: Bluetooth: hci_sync: fix HCI_CMD_DRAIN_WORKQUEUE fix", "", " * noble: generic kernel got a build failure against", " tools/perf/tests/builtin-test.c (LP: #2171033)", " - SAUCE: perf test: Fix setjmp clobber warning", "", " * Upstream stable patch causes build failure when", " CONFIG_SENSORS_RASPBERRYPI_HWMON is enabled (LP: #2170957)", " - SAUCE: Revert \"hwmon: (raspberrypi) Fix delayed-work teardown race\"", "", " * noble: bpf verifier loses scalar-ID precision propagation after 2026-09-02", " stable patchset (test_verifier \"precise\" tests fail) (LP: #2169943)", " - bpf: Track equal scalars history on per-instruction level", "", " * HMC error triggers cascading PF resets and tears down RDMA connections", " (LP: #2167995)", " - RDMA/irdma: Suppress PF reset on HMC error", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536)", " - netfilter: nfnetlink_queue: unbreak SCTP traffic", " - ipv4: validate checksum_start before completing checksum", " - ipv4: free inet_opt and ireq_opt after an RCU grace period", " - selftests/mm: hugetlb-mremap: add setup of HugeTLB pages", " - smb: client: use finish_no_open() for non-regular inodes", " - xfs: don't let memory failures leak blocks and kill repairs", " - RISC-V: KVM: Fix null pointer dereference in", " kvm_riscv_aia_imsic_has_attr()", " - ASoC: sdw_utils: Set snd_soc_dai_link_ch_map.codec_ch_mask for capture", " - Bluetooth: btusb: Add IMC Networks QCA9377 to quirks table", " - ASoC: SOF: ipc4-priv: Add kernel doc for fw_context_save of", " sof_ipc4_fw_data", " - ASoC: SOF: ipc4/Intel: Add support for library restore firmware", " functionality", " - smb/client: use stack-allocated smb2_file_all_info in", " smb3_query_mf_symlink()", " - smb/client: pass cifs_open_info_data to SMB2_open()", " - smb: client: close handle after create-context parsing failure", " - Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event", " paths", " - Bluetooth: ISO: release unused CIS holds after channel attach", " - smb: client: close completed creates on compound wait errors", " - xfs: fix cursor and pointer handling when recovering iunlink buckets", " - neighbour: Skip default parms when resumed in neightbl_dump_info().", " - ALSA: usb-audio: Apply IGNORE_CTL_ERROR quirk to all Audient devices", " - audit: fix exe mark UAF in kill_rules()", " - kprobes: Skip disarmed probes when checking optkprobe overlap", " - of/irq: Fix remaining refcount leaks in of_irq_init()", " - of/overlay: put property on deadprops only after changeset add succeeds", " - of/overlay: only treat a positive changeset id as registered", " - net: fix checksum offsets in skb_splice_from_iter()", " - netfilter: nft_flow_offload: drop flowtable reference on init error path", " - net/packet: prevent TX_RING byte count overflow", " - rtc: ac100: Assign .num before accessing .hws", " - rtc: spear: initialize IRQ state before requesting alarm IRQ", " - sctp: check RCV_SHUTDOWN after the sendmsg connect wait", " - rds_tcp: close NULL deref window in rds_tcp_set_callbacks", " - vt: skip screen update for DEC alignment test on backgroup consoles", " - wifi: wlcore: Fix runtime PM leak in wlcore_remove()", " - ALSA: caiaq: unregister the input device when probe fails", " - ALSA: line6: reject oversized playback packets", " - perf/core: Fix WARN in perf_sigtrap()", " - mm/damon/core: don't skip damos_adjust_quota() while esz is not zero", " - iio: accel: kionix-kx022a: Fix array boundary check", " - mtd: core: call _get_device() with the master MTD", " - nvmet: preserve device path on allocation failure", " - of/overlay: don't leak fragment references when changeset init fails", " - of/overlay: don't create \"//\" paths for fragments targeting the root", " - ASoC: wm8903: Move the DRC QR threshold to the register that holds it", " - wifi: wfx: validate MIB read length before copying to caller", " - ASoC: tegra: Fix ASRC Stream6 input threshold control", " - wifi: ath11k: reset ar->num_stations on hardware start", " - wifi: ath9k: reject short WMI command responses", " - wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE", " - rtc: dev: zero-initialize struct rtc_wkalrm to prevent information leak", " - rtc: ac100: Fix clock provider use-after-free on probe failure", " - rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe()", " - wifi: cfg80211: preserve hidden-group beacon IE ownership", " - wifi: mac80211: Add multicast to unicast support for 802.3 path", " - wifi: mac80211: Add 802.3 multicast encapsulation offload support", " - wifi: mac80211: prevent AP VLAN tx from other interfaces", " - ASoC: codecs: rt286: Revert delay value for jack setup", " - ASoC: codecs: rt274: Fix format setting for 44100 rate", " - Bluetooth: hci_core: free the HCI ID if naming fails", " - Bluetooth: btintel: validate DDC record lengths", " - net/mctp: publish the mctp_dev only after it is initialised", " - net/sched: cls_api: reclaim an empty proto on the error path", " - ipv6: fix prefix route expiry in modify_prefix_route()", " - netfilter: ipset: do not update comments from kernel-side adds", " - Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister", " - net: systemport: Fix buffer overflow in bcm_sysport_get_stats()", " - net: systemport: Fix RUNT MIB counter register offset calculation", " - net/mlx5: LAG, Refactor lag logic", " - net/mlx5: Fix slab-out-of-bounds when handling team device events", " - octeontx2-af: mcs: Fix SC resource cleanup loop", " - tipc: prevent GCM nonce reuse on peer key changes", " - memcg: convert memcg->socket_pressure to u64", " - mptcp: Fix up subflow's memcg when CONFIG_SOCK_CGROUP_DATA=n.", " - net: Clean up __sk_mem_raise_allocated().", " - net-memcg: Introduce mem_cgroup_from_sk().", " - net: add ", " - net-memcg: Introduce mem_cgroup_sk_enabled().", " - net: restrict SO_RESERVE_MEM to TCP sockets and cap max value", " - net/sched: fq_codel: match the no-drop threshold to the packet size", " - net/sched: sch_codel: match the no-drop threshold to the packet size", " - virtio_blk: set the zone write granularity", " - net: bcmgenet: fix NULL dereference in set_coalesce before first open", " - net: cap skb->queue_mapping when the tx queue is picked", " - net: ethernet: mtk_eth_soc: allocate dummy netdev sooner", " - tcp: refresh TS.Recent for accepted old ACKs", " - ipvs: fix missing counter decrement in lblc", " - ipvs: do not create invisible templates", " - ipvs: filter some flags received in the backup server", " - netfilter: bpf: reject invalid NAT manipulation types", " - netfilter: flowtable: generalize pending status bit", " - net: microchip: vcap: stop scanning after deleting key field", " - net: sparx5: make ports inherit the switch base mac address type", " - net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference", " - ipv6: sr: use skb_get_hash_net() in seg6_make_flowlabel()", " - xdp, xsk: constify read-only arguments of some static inline helpers", " - net: mvneta: clear XDP pfmemalloc flag between frames", " - i2c: at91: release DMA channels when probe defers", " - perf: Fix race between perf_event_exit_task() and perf_pending_task()", " - ALSA: core: Define auto-cleanup for snd_card_free()", " - ALSA: ice1712: Fix the error handling via auto-cleanup at probe", " - PCI: Accept AtomicOps already enabled by the hypervisor", " - drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend", " - drm/amd/pm/si: Check AMD_IS_MOBILITY flag for PPSMC_SYSTEMFLAG_GPIO_DC", " - drm/amd/pm/si: Fix updating clock limits on AC/DC", " - drm/amdgpu/gfx6: fix firmware leak on teardown", " - drm/radeon: Read the VRAM VBIOS signature with readb()", " - drm/mediatek: Add missing IS_ERR check for ovl_adaptor platform device", " - drm/mediatek: Fix ovl adaptor platform device leak", " - drm/mediatek: Fix pdev reference leak in mtk_drm_bind()", " - drm/amdgpu: fix IP instance memory leak on kobject add failure", " - drm/amdgpu: fix ACP MFD device leak on init failure", " - binder: fix is_failure flag for superseded transaction cleanup", " - binder: fix leaked fd fixups on TF_UPDATE_TXN supersede", " - kgdboc: Fix tty driver reference leak in configure_kgdboc()", " - Input: atkbd - skip deactivate for Lenovo IdeaPad Slim 3 15IWC11", " - Input: i8042 - add nomux quirk for Fujitsu LIFEBOOK U7410", " - Input: s6sy761 - fix resume ordering and restore sensing", " - Input: synaptics - add LEN205b entry to smbus_pnp_ids for ThinkPad T490", " - Input: synaptics - limit T440p InterTouch quirk to LEN0036", " - nitro_enclaves: fix use-after-free on SLOT_ALLOC failure", " - soc: qcom: geni-se: Correct QUP Core ICC vote constants", " - USB: cdc-acm: fix racy TIOCMIWAIT implementation", " - USB: cdc-acm: skip URB restart in port_shutdown if disconnected", " - USB: serial: fix port tear down use-after-free", " - usb: storage: sierra_ms: reject short SWoC info transfers", " - usb: hub: use shorter 120ms post resume hold for SS root hubs", " - usb: octeon-hcd: fix the FIFO-flush timeout computation", " - usb: ohci-da8xx: disable controller wakeup on cleanup", " - usb: ohci-s3c2410: disable controller wakeup on removal", " - usb: ohci-st: disable controller wakeup on removal", " - usb: gadget: midi2: Fix the jack descriptor array sizes", " - usb: gadget: f_uac1_legacy: validate bRequest index in", " generic_{set,get}_cmd", " - usb: typec: anx7411 - stop the IRQ before destroying the workqueue", " - usb: dwc3: am62: Fix runtime PM usage count leak on probe error path", " - usb: gadget: aspeed-vhub: cancel wake work on device removal", " - USB: gadget: dummy-hcd: Fix wait for outstanding request completions", " - usb: gadget: f_fs: Fix NULL pointer dereference in", " FUNCTIONFS_ENDPOINT_DESC", " - usb: chipidea: tegra: disable runtime PM on resume failure", " - usb: core: clear both ep_in and ep_out for non-ep0 control endpoints", " - usb: typec: tcpm: recover after failure to start the frs ams", " - usb: typec: tipd: don't send GAID when probe fails in APP mode", " - usb: typec: tipd: fix uninitialized typec_partner_desc in", " tps6598x_connect()", " - usb: typec: ucsi: glink: fix use-after-free of ucsi on remove", " - usb: typec: ucsi: Get the connector fwnode based on reg value", " - usb: typec: ucsi: displayport: Current CAM OOB index fixup", " - usb: cdns3: fix use-after-free in cdns3_gadget_exit()", " - usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe", " - tty: vt: fix memory leak in vc_allocate()", " - tty: amiserial: fix broken TIOCMIWAIT", " - tty: vcc: zero-initialize control packet in vcc_send_ctl()", " - tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup", " - tty: serial: qcom_geni_serial: Keep console RX functional after deep", " idle", " - tty: abort break signalling on hangup", " - tty: serial: max3100: shut down timer before freeing port", " - serial: 8250_bcm7271: fix use-after-free in brcmuart_remove()", " - serial: fix TIOCMIWAIT race", " - serial: ma35d1: Fix clock reference leak in ma35d1serial_probe()", " - serial: tegra: don't clear the Tx FIFO on an Rx-only reset", " - serial: vt8500: Fix clock reference leak in vt8500_serial_probe()", " - serial: sc16is7xx: refill TX FIFO below trigger using fresh TXLVL", " - ASoC: codecs: max98363: fix uninitialized stream_config->type", " - ASoC: codecs: rt1017-sdca-sdw: fix uninitialized stream_config->type", " - ASoC: qcom: lpass-cpu: use DAI table index for playback constraints", " - ALSA: seq: Serialize compat port-info ioctls", " - ALSA: ua101: reject mismatched capture/playback packet sizes", " - EDAC/altera: Fix memory leak on dci allocation failure", " - i2c: xiic: don't clobber msg->len to signal block-read completion", " - Bluetooth: RFCOMM: Fix initial port reference race", " - Bluetooth: hci_sync: Fix inquiry cache use-after-free", " - Bluetooth: hci_conn: Lock parent access during enhanced SCO setup", " - Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems", " - Bluetooth: hci_core: Serialize ACL scheduling with channel deletion", " - Bluetooth: hci_core: Serialize fragmented ISO packet queueing", " - Bluetooth: btintel: fix buffer over-read in btintel_hw_error()", " - ipvs: bound LBLCR and LBLC cache growth", " - HID: multitouch: stop the release timer from being rearmed on remove", " - net: extend IPv6 exthdr detection of tunneled packets", " - nvme-multipath: fix underflow in ANA log bounds checks", " - nvme-pci: add NVME_QUIRK_DMAPOOL_ALIGN_512 for Micron 4100AT", " - nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge()", " - block2mtd: prevent direct access of bd_inode", " - mtd: block2mtd: Fix divide error when erase_size is zero", " - mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ", " - mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of", " OOB", " - mtd: spinand: fix zero oobavail when no ECC engine is used", " - KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are", " modified", " - KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy", " - wifi: cw1200: fix TX padding OOB read leaking heap data to device", " - wifi: iwlegacy: 3945: free EEPROM data on remove", " - wifi: mac80211: keep paired old chanctx alive", " - wifi: mac80211: drain PS delivery work during station teardown", " - wifi: mac80211: account proxy paths against the mesh path limit", " - wifi: mac80211: keep fallback association elements alive", " - wifi: mac80211: minstrel_ht: validate fixed rate index", " - wifi: mac80211: release mesh path quota on failed additions", " - wifi: mac80211: fix mesh fast xmit path deletion UAF", " - wifi: mac80211: handle empty FILS association request payload", " - USB: serial: cp210x: add Corsair AX1500i Power Supply", " - USB: serial: quatech2: fix baud rate overflow", " - USB: serial: ssu100: fix baud rate overflow", " - USB: serial: fix dynamic id driver deregistration race", " - USB: serial: fix driver deregistration order", " - USB: serial: fix ioctl hangup race", " - USB: serial: option: add support for SIMCom SIM8260C", " - USB: serial: option: add Quectel EG060W", " - USB: serial: option: add Compal EXM-G1x support", " - USB: serial: option: add Quectel RG660QB", " - USB: serial: option: add Compal EXC-T1 support", " - thunderbolt: Fix KASAN reported use-after-free when request is canceled", " - thunderbolt: Disable CL states for the Anker Prime TB5 dock", " - thunderbolt: Reject oversized XDomain properties responses", " - smb: client: discard post-EOF pagecache when extending a file via zero", " range", " - smb: client: discard post-EOF pagecache when extending a file via copy", " range", " - smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races", " - iio: accel: kxcjk-1013: reject duplicate event disable", " - iio: accel: sca3000: fix frequency divider condition check", " - iio: adc: stm32-adc: fix check on internal channel availability", " - iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure", " - iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls", " - iio: adc: xilinx-xadc: free IRQ before cancelling the unmask worker on", " unbind", " - iio: admv1013: initialize callback mutex before registering notifier", " - iio: buffer: serialize buffer teardown with mode claims", " - iio: buffer: Ensure bounce buffer used for unaligned case is zeroed.", " - iio: frequency: admv1013: fix wrong channel field used in", " admv1013_read_raw()", " - iio: gyro: adis16136: fix unprotected debugfs reads", " - iio: core: add accessors 'masklength'", " - iio: health: max30102: make use of iio_get_masklength()", " - iio: health: max30102: fix NULL dereference in interrupt handler", " - iio: imu: adis16400: fix unprotected debugfs reads", " - iio: imu: adis16480: fix unprotected debugfs reads", " - iio: light: gp2ap020a00f: drain irq_work after free_irq", " - iio: pressure: bmp280: fix out-of-bounds access in sampling frequency", " lookup", " - iio: proximity: isl29501: Fix return type of isl29501_register_write", " - iio: proximity: pulsedlight: fix iio_device left registered on PM setup", " failure", " - iio: proximity: sx9324: Correct proximity channel resolution", " - iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler", " - iio: trigger: cancel reenable_work before freeing trigger", " - console: introduce console_lock guard()s", " - tty/vt: use guard()s", " - vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF", " - mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages", " - netfs: clear post-EOF pagecache when extending a file via write", " - net: usb: qmi_wwan: add Quectel EG120K-EA", " - fs,fsverity: reject size changes on fsverity files in setattr_prepare", " - fs,fsverity: remove check for fsverity being enabled in", " setattr_prepare()", " - drm/amd/display: Fix fast updates on DCE 8.1", " - usb: dwc3: gadget: fix IRQ storm on invalid event buffer count", " - tty: fix saved termios reset race", " - perf: Remove unnecessary parameter of security check", " - perf/core: Check kernel access when kernel callchains are requested", " - perf: Require kernel access for text poke events", " - arm64/fpsimd: signal: Clear PSTATE.SM when restoring FPSIMD frame only", " - arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only", " systems", " - Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown", " - Bluetooth: Serialize SMP remote OOB data access", " - arm64: errata: Factor out broken AMU const counter cap", " - arm64: errata: Add Cortex-A725 erratum 3821522 workaround", " - [Config] Enable ARM64 erratum workarounds for Cortex-A725 3821522", " - KVM: arm64: Use stage-1 leaf size for VM_PFNMAP", " - fsverity: add dependency on 64K or smaller pages", " - drm/amdgpu: reset VI ASIC on MacBookPro15,1", " - drm/amdgpu: reset VI ASIC on MacBookPro14,3", " - usb: ohci-spear: Remove unnecessary NULL check before", " clk_disable_unprepare()", " - usb: ohci-spear: disable controller wakeup on removal", " - USB: dwc2: shut down wakeup timer before freeing HCD state", " - drm/amd/display: Preserve eDP mode on initial ASSR failure", " - usb: typec: ucsi: acpi: Assume UCSI 1.2 on Acer Nitro ANV15-41", " - tty: introduce tty_port_tty guard()", " - tty: tty_port: use guard()s", " - tty: tty_port: restore TTY_IO_ERROR on activation failure", " - tty: n_gsm: fix missing modem controls after DLCI open in convergence", " layer type 2", " - perf: Replace perf_event_header__init_id with full header init", " - ALSA: hda/tegra: Re-enable SDO workaround for Tegra194", " - i2c: xiic: Relocate xiic_i2c_runtime_suspend and xiic_i2c_runtime_resume", " to facilitate atomic mode", " - i2c: xiic: preserve PEC byte length in SMBus block read setup", " - drm/amd/display: Mark DCE 6.4 as not APU", " - mtd: spinand: fix NULL pointer dereference with no ECC engine", " - wifi: mac80211: shut down RX BA session timer on teardown", " - mtd: spinand: Enable QE on all dies", " - bnxt_en: fix DMA mapping length for padded small packets", " - tty: port: fix tty_port_tty_vhangup() race", " - wifi: mac80211: count only matching reservations in reserved switch", " - fs: Free any excess xarray nodes in clear_inode()", " - net/mlx5e: Prevent stale XSK buffer release on refill retry", " - net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry", " - net: mana: check xdp_rxq registration before unreg in mana_destroy_rxq()", " - net: mana: Skip WQ object destruction for uninitialized RXQ", " - net: mana: remove double CQ cleanup in mana_create_rxq error path", " - KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is", " intercepted", " - wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()", " - wifi: mac80211: set info->band for 802.3 encap offload frames", " - iio: accel: kx022a: Use cleanup.h helpers", " - iio: accel: kionix-kx022a: Prevent memory leak and fix state", " - iio: adc: ad_sigma_delta: Follow renaming of SPI \"master\" to", " \"controller\"", " - iio: introduce struct iio_scan_type", " - iio: adc: ad_sigma_delta: fix use-after-free on unbind", " - iio: adc: aspeed: Simplify with dev_err_probe", " - iio: adc: aspeed: propagate reset deassert errors", " - iio: adc: max1363: sign-extend bipolar differential channel reads", " - iio: adc: axp288: Add TS bias override for Haier HV103H", " - iio: adc: stm32-adc: fix possible division by zero in processed channel", " - smb: client: only require read lease for size-extending preallocate", " - iio: cdc: ad7150: fix OF matching and publish module aliases", " - iio: bu27034: simplify using guard(mutex)", " - iio: light: rohm-bu27034: Fix infinite delay on error", " - iio: light: rohm-bu27034: Fix error return", " - tools: ynl-gen: support using pre-defined values in attr checks", " - ynl: ensure exact-len value is resolved", " - tools: ynl-gen: use names of constants in generated limits", " - tools: ynl-gen: support limits using definitions", " - tools: ynl: add scope qualifier for definitions", " - doc/netlink: netlink-raw: Add max check", " - f2fs: fix to reclaim space in f2fs_allocate_pinning_section()", " - f2fs: fix to shrink gc_lock coverage in f2fs_gc_range()", " - f2fs: fix to reset all pinned status during fggc", " - mm/damon/core: do non-safe region walk on kdamond_apply_schemes()", " - mm/damon/core: fix unconditionally skip last region", " - Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING", " - wifi: ath12k: fix reusing m3 memory", " - crypto: drbg - Fix ineffective sanity check", " - ipv4: stop PMTU walk when nexthop group shrinks", " - ipv4: stop exception dump when nexthop group shrinks", " - ipv4: stop route notification sizing when nexthop group shrinks", " - ipv4: do not warn on route notification size race", " - ipv6: do not warn on route notification size race", " - Input: xpad - add support for Corsair Novablade Pro", " - arm64: irq: exclude the softirq stack switch from KCOV", " - ASoC: amd: yc: Add DMI quirk for Acer Aspire Go 15 (AG15-21P)", " - btrfs: scrub: fix local_root reference leak in", " scrub_print_warning_inode()", " - dm ioctl: don't let data_start run past the buffer", " - usb: f81604: fix struct f81604_int_data size mismatch", " - wifi: brcmfmac: fix P2P device removal race in brcmf_detach()", " - wireguard: queueing: preserve tstamp_type when encapsulating packet", " - wireguard: noise: reject response consumption after intermediate", " initiation", " - workqueue: Fix NULL current_pwq deref in chained work check", " - xen/netfront: don't leak the skb when xennet_fill_frags() fails", " - tee: optee: Move pool_op helper functions", " - tee: fix memory leak in tee_dyn_shm_alloc_helper", " - tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()", " - strparser: make sure __strp_recv isn't running before tearing down the", " parser", " - swiotlb: fix default_swiotlb_limit() for non-growable default pool", " - tipc: destroy topsrv workqueues before closing connections", " - tipc: hold a reference to nodes found by link name", " - Revert \"wifi: libertas: reject short monitor TX frames\"", " - selinux: fix data race on AVC latest_notif", " - selinux: preserve NATIVE_LABELS on already-initialized sb in", " set_mnt_opts", " - sctp: copy zeroed stats to user in sctp_getsockopt_pr_streamstatus()", " when !streamoute", " - EDAC/amd64: Mask UMC chip select to the four implemented selects", " - gpio: xilinx: fix runtime PM leak on request error path", " - ibmveth: h_free logical LAN on open-fail after register", " - ibmveth: fix TX LTB and filter unwind on open-fail", " - ice: fix metadata_dst refcount handling on representor teardown", " - keys: finalize persistent keyring timeout after link attempt", " - KEYS: Fix add_key() race with keyring restriction", " - memstick: core: wait for request completion before freeing card", " - memstick: rtsx_usb_ms: complete requests after eject instead of dropping", " them", " - dm-crypt: reject the lmk IV mode with AEAD ciphers", " - dm-snap: reject the transient exception store for snapshot-merge", " - dm: fix reading free memory in do_resume", " - mmc: cavium-octeon: destroy slot platform devices on remove", " - mmc: cavium-thunderx: destroy slot platform devices on remove", " - mmc: mtk-sd: Cancel request timeout work on remove", " - mmc: sdhci-sprd: disable runtime PM on remove", " - net/packet: guard the ll header push in packet_rcv_spkt()", " - net/smc: protect clcsock lifetime in smc_getname", " - net: bridge: avoid recursive multicast port cleanup", " - net: dsa: microchip: fix KSZ8765 fiber detection", " - net: usb: ax88179_178a: fix rx frame length for non-last packets", " - nvme: fix swapped ZRASF zone state values for full and read only", " - openvswitch: fix soft lockup in the netlink flow dump", " - optee: register TEE devices only once fully initialized", " - regulator: ltc3676: don't read the write-only HRST and CLIRQ registers", " - regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4", " - pmdomain: imx8m-blk-ctrl: Serialize power on/off across sibling domains", " - pmdomain: rockchip: don't ignore clock lookup errors on attach", " - pmdomain: rockchip: fix clock leak on domain probe failure", " - pmdomain: rockchip: propagate subdomain add errors", " - scsi: qedi: Initialize callback state before registration", " - riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp", " - riscv: fix load_unaligned_zeropad() fixup for RV32", " - Bluetooth: hci_sock: Serialize dead-device detachment", " - Bluetooth: ISO: Reject concurrent BIS listener setup", " - Bluetooth: ISO: Serialize concurrent connect calls", " - Bluetooth: MGMT: Fix status of pending commands flushed on power off", " - Bluetooth: RFCOMM: free the skb when the DLC has no owner", " - Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown", " - drm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN", " - drm/gud: don't keep a connector without a CRTC as connector_state", " - drm/i915/gem: Prevent overstepping exec array boundary", " - drm/i915/gt: Unmask interrupts only when ACTIVE is true", " - drm/imagination: Size page table preallocation by device address", " - drm/vc4: drain the hangcheck timer and works on V3D unbind", " - drm/amdkfd: align SDMA doorbell base for shader doorbell writes", " - drm/amdkfd: fix dma_buf reference leak in get_dmabuf_info", " - drm/amdgpu: serialize vblank counter reads against GPU reset", " - drm/amdgpu: make Mac FB workaround generic", " - drm/amdgpu: copy debugfs register data outside the GRBM/SRBM locks", " - drm/amd/display: Fix direct scanout alpha on some DRM_FORMATs", " - namespace: don't copy an unmounted mount tree", " - fs: refuse fspick() on internal superblocks", " - namespace: check a submount for references right before unmounting it", " - dcache: don't put a mountpoint on a dentry that's being removed", " - namei: don't reveal overmounted entries in refwalk", " - namespace: refuse an automount below a mount that is in no namespace", " - drm/dp: don't mark the AUX backlight enabled when enabling failed", " - gpio: exar: initialize the ID before registering its cleanup", " - drm/aspeed: Balance the display clock enable on teardown", " - drm/vc4: Free the BO cache size list on teardown", " - net/sched: em_text: reject unterminated algo before autoload", " - amt: send the relay's General Query directly from the receive path", " - cxgb4/ch_ktls: disable softirqs around tid_list erases", " - optee: sync secure world ABI headers", " - tee: optee: fix kernel-doc warnings", " - tee: optee: ffa: support shared memory offsets on large-page kernels", " - nvmet: use the local P2P device on metadata allocation failure", " - btrfs: fix xattr replace when multiple xattrs are packed in the same", " item", " - wifi: mt76: mt7996: fix struct mt7996_mcu_wed_rro_ba_delete_event layout", " - wifi: mt76: mt7915: disable rx napi when removing device", " - wifi: mt76: mt7925: don't put the band auto marker in TGID", " - wifi: mt76: mt792x: treat 0xff ACPI SAR entries as no limit", " - wifi: mt76: mt792x: pick the SAR table layout from the table itself", " - ASoC: adau1372: allow sleepy powerdown GPIOs", " - ASoC: adau1372: fix invalid default state of output ASRC and DAC muxes", " - ASoC: samsung: i2s: enable op_clk in probe to balance runtime PM", " - cpuset: separate tmpmasks and cpuset allocation logic", " - cgroup/cpuset: Call is_in_v2_mode() after acquiring cpuset_mutex in", " cpuset_handle_hotplug()", " - flow_dissector: avoid u16 truncation of skb->len when computing thoff", " - devlink: fix devlink_rel reference leak when notify work is pending", " - net/sched: cls_route: reject change with no routing attribute", " - bnxt_en: Add bnxt_clear_bars() helper", " - bnxt_en: Fix driver init in kdump kernel", " - flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()", " - drm/imagination: Fix reference and vm_bo handling in remap()", " - veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down", " - net/mlx5e: Order ICOSQ cc update after CQ doorbell", " - mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()", " - net: openvswitch: validate transport header presence in set_ipv6_addr", " - vsock: Fix memory leak in vmci_transport_recv_dgram_cb()", " - drm/vc4: Make v3d paths unavailable on any generation newer than vc4", " - drm/vc4: Fix binner slot allocation failing on an idle GPU", " - io_uring/waitid: use io_waitid_remove_wq() consistently", " - io_uring/waitid: fix KCSAN warning on io_waitid->head", " - netfilter: conntrack: fix erronous removal of offload bit", " - netfilter: flowtable: fix offloaded ct timeout never being extended", " - wifi: mt76: mt7603: initialize global station WCID", " - can: fix unique skb identifier regression under RPS", " - drm/amd/display: Don't replace a sink mode that shares the native totals", " - HID: steam: Fully unregister controller when hidraw is opened", " - HID: steam: Rearrange teardown sequence", " - HID: steam: Refactor registration", " - HID: steam: Clean up locking", " - Upstream stable to v6.6.159, v6.12.113", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2024-50169.", " - vsock/virtio: account only unread bytes in read_skb()", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-98375", " - xen/netfront: drop RX packets with a short Ethernet header", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-97567", " - mptcp: prevent race between disconnect() and rtx", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-93179", " - drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-89527", " - svcrdma: Use svc_xprt_put to free listener on create failure", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-89912", " - KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2025-38204", " - jfs: fix array-index-out-of-bounds read in add_missing_indices", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2025-40158", " - ipv6: use RCU in ip6_output()", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-93243", " - mm/secretmem: properly account locked pages", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-89638", " - smb: client: clear setuid/setgid bit on write with", " cifsacl/modefromsid/posix extensions", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-90146", " - bpf, xdp: move offload check into dev_xdp_install()", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-97558", " - smb: client: fix cifsFileInfo reference leak in deferred close", "", " * Noble update: upstream stable patchset 2026-10-21 (LP: #2171536) //", " CVE-2026-89633", " - smb: client: fix OOB read/write from unvalidated DataOffset in", " coalesce_t2()", "" ], "package": "linux", "version": "6.8.0-149.149", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2171733, 2167919, 2171033, 2170957, 2169943, 2167995, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536, 2171536 ], "author": "Stefan Bader ", "date": "Fri, 23 Oct 2026 14:10:26 +0200" }, { "cves": [ { "cve": "CVE-2026-74350", "url": "https://ubuntu.com/security/CVE-2026-74350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate fast symlink target during inode read ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment. A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer. Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated. This keeps malformed fast symlinks from reaching the read path. Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x19f/0x330 (?:?) kasan_report+0xe0/0x110 (?:?) kasan_check_range+0x105/0x1b0 (?:?) __asan_memcpy+0x23/0x60 (?:?) filemap_read_folio+0x27/0xe0 (?:?) filemap_read_folio+0x35/0xe0 (?:?) do_read_cache_folio+0x138/0x230 (?:?) __page_get_link+0x26/0x110 (?:?) page_get_link+0x2e/0x70 (?:?) vfs_readlink+0x15e/0x250 (?:?) touch_atime+0x4d/0x370 (?:?) do_readlinkat+0x186/0x200 (?:?) do_user_addr_fault+0x65a/0x890 (?:?) __x64_sys_readlink+0x46/0x60 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-97559", "url": "https://ubuntu.com/security/CVE-2026-97559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fail DACL rewrite when the new DACL exceeds 64K replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97566", "url": "https://ubuntu.com/security/CVE-2026-97566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97594", "url": "https://ubuntu.com/security/CVE-2026-97594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Fix use-after-free of the source's parent directory current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record. A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent. hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it. hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() runs, and the former parent can then be removed and freed while the hook walks it. A process can trigger this after entering a Landlock domain that handles at least one filesystem access right. The process can then race a linkat(2) loop against rename(2) and rmdir(2): BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290 Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549 collect_domain_accesses+0x278/0x290 current_check_refer_path+0x952/0x1120 security_path_link+0x1be/0x320 filename_linkat+0x342/0x6d0 __x64_sys_linkat+0xfa/0x150 Freed by task 562: kmem_cache_free+0x139/0x4c0 i_callback+0x4b/0x80 rcu_core+0x7dc/0x10a0 Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging. [mic: Clarify the caller, reachability, and reference handling]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97597", "url": "https://ubuntu.com/security/CVE-2026-97597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97609", "url": "https://ubuntu.com/security/CVE-2026-97609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: prevent UAF during module unload nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook. This allows the following interleaving: CPU 0 CPU 1 cttimeout_exit() nf_ct_set_timeout() unregister_pernet_subsys() rcu_read_lock() kfree(pernet) h = nf_ct_timeout_hook h->timeout_find_get() nfct_timeout_pernet() The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported: BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get Read of size 8 by task poc/90 Call Trace: ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout] nf_ct_set_timeout+0x7b/0x3c0 xt_ct_tg_check+0x724/0xb20 xt_check_target+0x234/0xa90 do_ipt_set_ctl+0x570/0x1270 Allocated by task 89: __kmalloc_noprof+0x16e/0x460 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 Freed by task 91: kfree+0x131/0x390 ops_undo_list+0x3d4/0x730 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout] Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74347", "url": "https://ubuntu.com/security/CVE-2026-74347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released. Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object. Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed. nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed. nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-97620", "url": "https://ubuntu.com/security/CVE-2026-97620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 (\"anv: don't prevent L1 untyped cache flush in 3D mode\"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 (cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97615", "url": "https://ubuntu.com/security/CVE-2026-97615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use option bits for CFM/MRP frame handlers CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another. These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case. Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97906", "url": "https://ubuntu.com/security/CVE-2026-97906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bootconfig: Fix integer overflow in initrd size check Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97619", "url": "https://ubuntu.com/security/CVE-2026-97619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: end write accounting from ->ki_complete Commit b000145e9907 moved both the fsnotify calls and the write accounting out of the kiocb completion handler and into the io_req_rw_complete() task_work. However, only the fsnotify part actually needed to move as it may sleep. Ending the write accounting is just a percpu_up_read() on the superblock writers sem. Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE protection depend on the ring owner getting to running task_work. But the task may be blocked in freeze_super(), causing it to never get to that: task io-wq worker -------------------------------------------------------------- io_write() io_kiocb_start_write() (takes sb_writers, hidden from lockdep by __sb_writers_release) write_iter() -> -EIOCBQUEUED ioctl(FS_IOC_SHUTDOWN) bdev_freeze() freeze_super() percpu_down_write() <- waits for the reader above io_write() kiocb_start_write() percpu_down_read() <- queued behind the writer io_complete_rw() queues io_req_rw_complete() <- never runs, task is in D state End the write from io_complete_rw() instead, and leave only the fsnotify calls in task_work.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97901", "url": "https://ubuntu.com/security/CVE-2026-97901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: genetlink: pin family module during policy dump The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request. Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module. Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97918", "url": "https://ubuntu.com/security/CVE-2026-97918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Undo the registration when enabling the histogram trigger fails Commit 6f86bdeab633 (\"tracing: Fix bad hist from corrupting named_triggers list\") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled: \tlist_add_tail_rcu(&data->list, &file->triggers); \tupdate_cond_flag(file); \tif (trace_event_trigger_enable_disable(file, 1) < 0) { \t\tlist_del_rcu(&data->list); \t\tupdate_cond_flag(file); \t\tret--; \t} so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 69: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind. Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well. Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97919", "url": "https://ubuntu.com/security/CVE-2026-97919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take the reference before publishing the named histogram trigger event_hist_trigger_named_init() puts the trigger on the global named_triggers list and only then takes the reference on the trigger it shares its histogram with: \tdata->ref++; \tsave_named_trigger(data->named_data->name, data); \tret = event_hist_trigger_init(data->named_data); \tif (ret < 0) { \t\tkfree(data->cmd_ops); \t\tdata->cmd_ops = &trigger_hist_cmd; \t} \treturn ret; event_hist_trigger_init() fails when alloc_hist_pad() cannot allocate, and nothing takes the trigger back off the list on the way out. event_hist_trigger_parse() frees it, and the next lookup by name reads the freed object: BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff888009346860 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0xa00 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 67: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Do the reference first and publish once it has succeeded, so that nothing which can fail runs after the trigger becomes findable.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97933", "url": "https://ubuntu.com/security/CVE-2026-97933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening a tracer options file When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened. Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased. Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97935", "url": "https://ubuntu.com/security/CVE-2026-97935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: \tif (data->cmd_ops->init) { \t\tret = data->cmd_ops->init(data); \t\tif (ret < 0) \t\t\tgoto out; \t} \tif (hist_data->enable_timestamps) { \t\tret = tracing_set_clock(file->tr, hist_data->attrs->clock); \t\tif (ret) { \t\t\thist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); \t\t\tgoto out; \t\t} The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object: ~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160 Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 (\"tracing: Fix bad hist from corrupting named_triggers list\") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97949", "url": "https://ubuntu.com/security/CVE-2026-97949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: unhash the dentry before dropping the item in rmdir configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item. configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned. configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window: BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90 get_target fs/configfs/symlink.c:128 [inline] configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185 Unhash in configfs_remove_dir(), while the item is still guaranteed to be there. A reference obtained just before that stays harmless, as create_link() rechecks CONFIGFS_USET_DROPPING, already set by configfs_detach_prep(). Both configfs_unregister_subsystem() paths d_drop() after detaching, so this only makes rmdir match them.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97938", "url": "https://ubuntu.com/security/CVE-2026-97938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reboot: fix cad_pid use-after-free race cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid)", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97939", "url": "https://ubuntu.com/security/CVE-2026-97939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmr: account multicast table and route memory A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count. Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names. Unresolved MFC entries are still allocated from softIRQ with GFP_ATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 (\"ipmr: remove hard code cache_resolve_queue_len limit\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97934", "url": "https://ubuntu.com/security/CVE-2026-97934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from a \"STACKTRACE\" histogram key \"cpu\", \"CPU\", \"stacktrace\" and \"STACKTRACE\" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97950", "url": "https://ubuntu.com/security/CVE-2026-97950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: pin the symlink target's dirent instead of chasing ->ci_dentry create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target(). That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive. A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get(). Take the dirent in get_target() as well, under ->d_lock and atomically with the item reference, and pass it down to create_link(). A hashed dentry has not been killed yet, so its ->d_fsdata reference keeps the dirent alive there.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89806", "url": "https://ubuntu.com/security/CVE-2026-89806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation The framebuffer size calculation `fb_size = linebytes * height` can overflow when both values are large (e.g., 46341 * 46341 > INT_MAX). Since linebytes and height are both int types, the multiplication is performed as int * int, which results in undefined behavior on overflow. Use check_mul_overflow() to detect and prevent this overflow, consistent with the approach used in simpledrm.c and corebootdrm.c.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93244", "url": "https://ubuntu.com/security/CVE-2026-93244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: simpledrm: Improve stride validation Validate the computed stride against the maximum value INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89827", "url": "https://ubuntu.com/security/CVE-2026-89827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid force-completing uninitialized UVD rings uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF. However, amdgpu_uvd_resume() unconditionally force-completes the decode ring when restoring its fence sequence. Skip fence completion when the fence driver is not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97534", "url": "https://ubuntu.com/security/CVE-2026-97534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: accurately adjust free_sections during free_segment_range In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC. However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight. Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89832", "url": "https://ubuntu.com/security/CVE-2026-89832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty flag on folio in error path If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93285", "url": "https://ubuntu.com/security/CVE-2026-93285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: embed f2fs_gc_kthread in f2fs_sb_info Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown. - __sbi_store\t\t\t- remount|shutdown \t\t\t\t - f2fs_stop_gc_thread - access sbi->gc_thread \t\t\t\t - sbi->gc_thread = NULL - access sbi->gc_thread->f2fs_gc_task", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-89837", "url": "https://ubuntu.com/security/CVE-2026-89837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dentry folio leak in find_in_level find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block(). If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio. This leaks the folio reference on the find_in_block() error path. Drop the dentry folio before returning the error to the caller.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89838", "url": "https://ubuntu.com/security/CVE-2026-89838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: limit recovery filename logging to stored length F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s. For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields. Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.", "cve_priority": "negligible", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89840", "url": "https://ubuntu.com/security/CVE-2026-89840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate MOVE_RANGE destination size F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len. Reject destination overflow and use inode_newsize_ok() before extending the destination inode.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97529", "url": "https://ubuntu.com/security/CVE-2026-97529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] The FC BSG transport allocates job->request via memdup_user() using the exact user-supplied request_len. For FC_BSG_HST_VENDOR, fc_bsg_host_dispatch() only guarantees request_len covers msgcode and vendor_id; it does not account for the vendor_cmd[] flexible array. qla2xxx then reads the command selector vendor_cmd[0] and, in several sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor command area without verifying request_len. A caller holding CAP_SYS_RAWIO can submit a short request whose vendor_id matches the host, triggering out-of-bounds heap reads (KASAN-detectable, and able to mis-select a command or panic). Add a central guard in qla2x00_process_vendor_specific() so the selector is always in bounds, restrict the early vendor_cmd[0] read in qla24xx_bsg_request() to sufficiently long vendor messages, and add request_len checks to the sub-handlers that read further: qla24xx_proc_fcp_prio_cfg_cmd(), qla2x00_process_loopback(), qla84xx_reset(), qla84xx_updatefw(), qla2x00_read_optrom(), qla2x00_update_optrom(), qlafx00_mgmt_cmd() and qla28xx_validate_flash_image().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97527", "url": "https://ubuntu.com/security/CVE-2026-97527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock The fcport->unsol_ctx_head list is modified from several contexts without a common lock. Entries are added in qla2xxx_process_purls_iocb() from the response queue ISR (under the qpair qp_lock), while they are removed from qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp() (NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB completion). The qpair qp_lock cannot serialize this per-fcport list since multiqueue adapters add entries through different qpairs, so a concurrent add and delete (or two concurrent deletes) can corrupt the list pointers. Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del() on unsol_ctx_head. The add nests under the existing qp_lock; no delete path takes qp_lock, so the lock order is consistent and deadlock free.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97528", "url": "https://ubuntu.com/security/CVE-2026-97528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error qla_nvme_xmt_ls_rsp() obtains uctx, which was linked into fcport->unsol_ctx_head by qla2xxx_process_purls_iocb() and is still linked when the NVMe transport calls back to transmit the LS response. On the error (out:) path the function frees uctx with kfree() but never removes it from the list. This leaves a freed node in fcport->unsol_ctx_head: the next list_add_tail() for that fcport writes through the freed node, and a subsequent list_del() can corrupt the list or panic. Unlink uctx with list_del() before kfree() on the error path, matching the other free sites in qla_nvme_release_lsrsp_cmd_kref() and qla2xxx_process_purls_pkt(). qla2x00_rel_sp() in the failure path only returns the SRB to its pool and does not invoke sp->put_fn, so the out: path is the sole free and uctx is always still linked there.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97530", "url": "https://ubuntu.com/security/CVE-2026-97530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide whether the next continuation IOCB has arrived, spinning on cpu_relax() without advancing the ring or decrementing the entry count while it has not. response_t::signature lives at byte offset 60, but a continuation IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame payload at that offset (data[56..59]). A received frame whose payload bytes happen to equal 0xDEADDEAD is therefore misread as \"not yet arrived\", and the loop spins forever in interrupt/DPC context, causing a CPU soft lockup. The poll is also unnecessary: callers of qla27xx_copy_multiple_pkt() (PT_LS4_UNSOL and the NVMe purls path) already gate on qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are present before copying begins. The sibling helper __qla_copy_purex_to_buffer() already drops the signature poll and relies on the entry_type == STATUS_CONT_TYPE guard instead. Remove the signature busy-wait from both helpers, keeping the entry_type guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers and re-processes on the next interrupt once all continuation IOCBs have arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the signature field is never read on a continuation IOCB, eliminating the payload-aliasing lockup.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97531", "url": "https://ubuntu.com/security/CVE-2026-97531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip vport under deletion in report ID acquisition qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id. A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory. Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89868", "url": "https://ubuntu.com/security/CVE-2026-89868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add timeout while stop_streaming When stop_streaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPU_DEC_STOP_TIMEOUT elapses.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-97535", "url": "https://ubuntu.com/security/CVE-2026-97535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array. max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout). Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97532", "url": "https://ubuntu.com/security/CVE-2026-97532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to probe_hw_failed and calls qla2x00_mem_free(). Several error labels in qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool, flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info) but left the pointers dangling. qla2x00_mem_free() then freed them a second time. Worse, for the dma_pool members it issued dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been destroyed and set to NULL at fail_s_dma_pool, dereferencing a NULL pool. Clear each freed pointer (and its DMA handle) in the error labels so the subsequent qla2x00_mem_free() skips them.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97536", "url": "https://ubuntu.com/security/CVE-2026-97536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair->qp_lock. During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha->wq) forces pending work to run after the queue pairs have been freed. Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97537", "url": "https://ubuntu.com/security/CVE-2026-97537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que(): 1. When dma_alloc_coherent() fails during queue creation, the error path calls the free function with req->ring / rsp->ring still NULL (from kzalloc). The unconditional dma_free_coherent() with a NULL cpu_addr is undefined behavior and can panic. 2. The free functions clear req_qid_map / rsp_qid_map under vport_lock, but the create functions protect the same bitmaps with mq_lock. This provides no mutual exclusion. Additionally, the create error path clears the bit and releases mq_lock before calling the free function, creating a window where another thread can allocate the same que_id and have its ha->req_q_map entry clobbered by the subsequent lockless NULL assignment in the free function. Fix by: - Guarding dma_free_coherent() with a NULL check on the ring pointer. - Using mq_lock (the lock held by all creators) in the free functions to atomically NULL the map entry and clear the bitmap bit. - Removing the now-redundant clear_bit blocks from the create error paths since the free functions handle it atomically.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89859", "url": "https://ubuntu.com/security/CVE-2026-89859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space. Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89921", "url": "https://ubuntu.com/security/CVE-2026-89921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-93196", "url": "https://ubuntu.com/security/CVE-2026-93196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: virtio_pmem: refcount requests for token lifetime KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-98161", "url": "https://ubuntu.com/security/CVE-2026-98161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm: pmem: keep PREFLUSH before data writes pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier. Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.", "cve_priority": "low", "cve_public_date": "2026-09-25 14:17:00 UTC" }, { "cve": "CVE-2026-89956", "url": "https://ubuntu.com/security/CVE-2026-89956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89972", "url": "https://ubuntu.com/security/CVE-2026-89972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: add missing SRCU grace period in error path nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89996", "url": "https://ubuntu.com/security/CVE-2026-89996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious \"close it on the failure path\" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/ remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90002", "url": "https://ubuntu.com/security/CVE-2026-90002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Take trace_array reference before accessing its ftrace_ops The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel. Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used. This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90013", "url": "https://ubuntu.com/security/CVE-2026-90013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening options file The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used. As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array. One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90016", "url": "https://ubuntu.com/security/CVE-2026-90016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: \twhile (i < in_len) { \t\t... \t\tif (i + 5 < in_len && in_ie[i] == 0xDD && ...) { \t\t\t... \t\t\tbreak; \t\t} \t\ti += (in_ie[i + 1] + 2); /* to the next IE element */ \t} When the \"i + 5 < in_len\" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to \"i += (in_ie[i + 1] + 2)\", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f (\"staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie\") added the \"i + 5 < in_len\" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90023", "url": "https://ubuntu.com/security/CVE-2026-90023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90029", "url": "https://ubuntu.com/security/CVE-2026-90029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80935", "url": "https://ubuntu.com/security/CVE-2026-80935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy mt7996_mcu_get_eeprom() derives the destination of the EFUSE/EXT block copy from the address reported by the MCU response (event->addr, a device-controlled __le32) and clamps only the copy length, never the destination offset into dev->mt76.eeprom.data. A malicious or malfunctioning device can report an arbitrary address and drive an out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80939", "url": "https://ubuntu.com/security/CVE-2026-80939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot: SError Interrupt on CPU8, code 0x00000000be000011 -- SError Workqueue: events_power_efficient rfkill_poll [rfkill] rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci] rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core] rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core] ieee80211_rfkill_poll+0x3c/0x70 [mac80211] cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211] rfkill_poll+0x30/0x88 [rfkill] Kernel panic - not syncing: Asynchronous SError Interrupt On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64. Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs. This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-90030", "url": "https://ubuntu.com/security/CVE-2026-90030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: clear forceRM when issuing EndTransfer The forceRM bit of the DEPCMD register controls the behavior of the EndTransfer command used to stop an active transfer. Older DWC3 programming guide revisions recommended setting forceRM=1 when issuing EndTransfer. Newer programming guide revisions recommend issuing EndTransfer with forceRM cleared. With forceRM=1 on DWC_usb31 v2.00a and v2.10a controllers, a transfer aborted through the ep_dequeue path was observed to remain active after EndTransfer completion. A subsequent StartTransfer issued on the same endpoint triggered writes associated with the aborted transfer. This resulted in an SMMU fault because the transfer buffer had already been unmapped during EndTransfer command-completion cleanup. Using forceRM=0 eliminates the issue. Although older DWC3 programming guide revisions recommended setting forceRM=1, no issues are known from using forceRM=0. Clear forceRM when issuing EndTransfer to provide consistent EndTransfer behavior and align with newer programming guide recommendations.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-93200", "url": "https://ubuntu.com/security/CVE-2026-93200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix use-after-free of master->this sysfs attribute callbacks for the master controller device dereference master->this. However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released. As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free. Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path. On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-80937", "url": "https://ubuntu.com/security/CVE-2026-80937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver's dev->mt76.eeprom.data buffer at the offset reported by the MCU response (res->addr, a device-controlled __le32) without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data. Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-93199", "url": "https://ubuntu.com/security/CVE-2026-93199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Do not treat master device as a duplicate target i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device. The search can match master->this, causing the controller itself to be returned as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. Exclude master->this from matching so that the function only returns real duplicate target devices.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-80980", "url": "https://ubuntu.com/security/CVE-2026-80980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: stop killed, freed and out_of_sync sharing a byte The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock(). Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89467", "url": "https://ubuntu.com/security/CVE-2026-89467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: qcom_battmgr: fix use-after-free qcom_battmgr_pdr_notify() queues enable_work when the PMIC GLINK service comes up, and the worker recovers battmgr through container_of() to issue firmware requests. The PMIC GLINK client stays on the client list until its devres release action runs, so a PDR notification can keep queueing the work, and a pending or running worker can access battmgr after devres frees it. Make enable_work device-managed with devm_work_autocancel(), registered before the PMIC GLINK client is allocated. The devres cleanup then releases the client first, so no further notification can queue the work, and cancels the work before battmgr is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81016", "url": "https://ubuntu.com/security/CVE-2026-81016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. \"SMU cmd failed. err: 0xff\") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89437", "url": "https://ubuntu.com/security/CVE-2026-89437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: int1092: Fix potential memory leak in sar_probe() The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89795", "url": "https://ubuntu.com/security/CVE-2026-89795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: Allow per function PCI slots to fix slot reset on s390 On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 (\"s390/pci: Handling multifunctions\") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89441", "url": "https://ubuntu.com/security/CVE-2026-89441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: cancel card-detect work on remove Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory. Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89452", "url": "https://ubuntu.com/security/CVE-2026-89452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/msm: Unwind probe state on registration failure msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core. If iommu_device_sysfs_add() fails, probe returns with the object still on qcom_iommu_devices. The driver core then releases the devm allocation, leaving a dangling list entry that later list walks may dereference. If iommu_device_register() fails, the same dangling list entry remains and the sysfs device is left registered as well. Unwind the sysfs device and global list entry in reverse setup order on the corresponding failure paths.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89797", "url": "https://ubuntu.com/security/CVE-2026-89797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500_fg: fix use-after-free on remove ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue. Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-93231", "url": "https://ubuntu.com/security/CVE-2026-93231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: fix swapped arguments in nlmsvc_match_ip() When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument: \tnlm_traverse_files(server_addr, nlmsvc_match_ip, NULL); The match callback is later invoked from nlm_traverse_locks() as: \tmatch(lockhost, host); where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr). This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value. nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d (\"lockd: unlock lockd locks associated with a given server ip\"): \treturn rpc_cmp_addr(nlm_srcaddr(host), datap); Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr. As a result the comparison practically never matches and locks are not released for the requested IP. Swap the arguments so the lock owner's source address is compared against the requested server address: \treturn rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host); [ cel: fix the misleading typedef parameter names too ]", "cve_priority": "low", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89500", "url": "https://ubuntu.com/security/CVE-2026-89500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page Discarding a cached reader page after a concurrent ring buffer resize uses the new global subbuf_order for the free_pages() call. This mismatched order may crashes the kernel or leaks memory because the cached page was allocated under the old size. Save the actual free_page order alongside the page address to ensure we always refer to the correct value and do not rely on the potentially stalled cpu_buffer->subbuf_order value. The simplest is to make free_page a buffer_data_read_page which already covers exactly what we need: a page address and a page order.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89520", "url": "https://ubuntu.com/security/CVE-2026-89520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/core: Make core-sched flips wait for in-flight selections Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events. sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89503", "url": "https://ubuntu.com/security/CVE-2026-89503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set, it can allocate a reader page with an outdated order. This isn't a big issue, the user can still re-allocate a new reader page and try again. However, what is more problematic is if the value of subbuf_order changes in the middle of ring_buffer_alloc_read_page(). In that case, bpage->order might not match the actual allocated memory. Use bpage->order for the allocation to prevent this race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2025-37807", "url": "https://ubuntu.com/security/CVE-2025-37807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kmemleak warning for percpu hashmap Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.", "cve_priority": "negligible", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2026-72315", "url": "https://ubuntu.com/security/CVE-2026-72315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix busy dentry warning on unmount after DIO Commit c68337442f03 (\"cifs: Fix busy dentry used after unmounting\") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb() to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: \t[dio]\t\t\t[cifsd]\t\t\t[close + umount] netfs_unbuffered_write_iter_locked ... \t\t\t\tcifs_demultiplex_thread netfs_unbuffered_write cifs_issue_write netfs_wait_for_in_progress_stream [1] \t\t\t\t... \t\t\t\t netfs_write_subrequest_terminated \t\t\t\t netfs_subreq_clear_in_progress \t\t\t\t netfs_wake_collector // wake [1] \t\t\t\t netfs_put_subrequest netfs_put_request queue_work(system_dfl_wq, xxx) [2] // dio write return\t\t\t\t\tcifs_close \t\t\t\t\t\t\t _cifsFileInfo_put \t\t\t\t\t\t\t // cfile->count 2->1 \t\t\t\t\t\t\t --cfile->count [3] \t\t\t\t\t\t\t// umount \t\t\t\t\t\t\tcifs_kill_sb \t\t\t\t\t\t\t kill_anon_super \t\t\t\t\t\t\t // warning triggered! \t\t\t\t\t\t\t shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request ... _cifsFileInfo_put // cfile->count 1->0 --cfile->count queue_work(fileinfo_put_wq, xxx) [fileinfo_put_wq] [6] cifsFileInfo_put_work cifsFileInfo_put_final dput If the umount path is triggered before [5], it results warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] The existing per-inode ictx->io_count wait in cifs_evict_inode() does not help: it lives in the inode eviction path, which runs after shrink_dcache_for_umount() has already warned about the busy dentries. Fix it by adding a per-superblock outstanding-rreq counter that is incremented in cifs_init_request() and decremented in cifs_free_request(). In cifs_kill_sb(), before kill_anon_super(), wait for this counter to reach 0 - which guarantees that all cleanup_work for this sb have run and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Then drain the workqueue so the dentry refs are dropped. This is a targeted wait, not a flush of the system-wide system_dfl_wq.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89492", "url": "https://ubuntu.com/security/CVE-2026-89492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate directory-index entry counts when reading metadata ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks \tfor (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) \t\tdx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f (\"ocfs2: validate dx_root extent list fields during block read\") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-93228", "url": "https://ubuntu.com/security/CVE-2026-93228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Reject Write/Reply chunks with segcount 0 A peer can send a Write or Reply chunk whose segcount field is zero. xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero passes the range check, and xdr_inline_decode(stream, 0) returns the current (non-NULL) cursor without advancing. The function returns true and pcl_alloc_write() then links a struct svc_rdma_chunk with ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl. An earlier patch in this series made pcl_for_each_segment() safe for ch_segcount == 0, so this no longer drives the memory walk it used to. Rejecting the malformed frame at the decode boundary is still worthwhile as defense in depth: it keeps degenerate zero-segment chunks off the parsed chunk lists entirely, so any future consumer that walks ch_segments directly cannot observe one, and it makes the zero-floor easy to backport to trees where the macro change is more intrusive. RFC 8166 has no meaning for a Write/Reply chunk that describes no remote buffer, so no legitimate client is affected. xdr_check_reply_chunk() funnels Reply chunks through xdr_check_write_chunk() and inherits the same rejection. pcl_alloc_write() also links each chunk onto the parsed chunk list before filling its segment array. If a future change weakens the segcount-0 rejection, an incomplete chunk is visible to consumers during the fill loop. Reorder so that list_add_tail() follows the segment fill loop, ensuring only fully-populated chunks appear on the list.", "cve_priority": "medium", "cve_public_date": "2026-09-24 16:17:00 UTC" }, { "cve": "CVE-2026-89543", "url": "https://ubuntu.com/security/CVE-2026-89543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir Normal client creation goes through rpc_setup_pipedir(), which records clnt->pipefs_sb, but the mount-event path in __rpc_clnt_handle_event() calls rpc_setup_pipedir_sb() directly and never refreshes that field. The umount path also removes the directory without clearing clnt->pipefs_sb. After a late pipefs mount or any remount, rpc_clnt_remove_pipedir() compares the current superblock against a stale pipefs_sb pointer and skips cleanup, leaving pipefs dentries whose inode private data still points at a freed rpc_clnt, leading to a potential use-after-free during subsequent rpc_info_open() or rpc_show_info() calls. Fix this by properly updating clnt->pipefs_sb upon mount events and clearing it during unmount or failure paths.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89544", "url": "https://ubuntu.com/security/CVE-2026-89544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gssx_dec_option_array error path bugs Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose. gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gssp_accept_sec_context_upcall() gssx_dec_accept_sec_context() gssx_dec_option_array() /* fails, count=1 data=NULL */ data = res.options.data[0].value /* NULL deref */ Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation. The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory. Fix all four together: - Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array. - Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc. - In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89545", "url": "https://ubuntu.com/security/CVE-2026-89545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: defer rq_argp and rq_resp free until after RCU grace period svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu(). After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp. These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free. Fix this by moving the kfree of rq_argp and rq_resp into an explicit call_rcu() callback alongside the struct free. Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain synchronously freed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89564", "url": "https://ubuntu.com/security/CVE-2026-89564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip: orphan prefetched skbs before multicast forwarding IPv4 and IPv6 input preserve an skb->sk association installed by bpf_sk_assign() so that local delivery can use the selected socket under RCU. Both address families can also prefetch a socket in UDP early demux. In both paths (BPF and UDP early demux) a reference is not guaranteed to be held on the socket. When a multicast packet is not locally deliverable, IPv6 hands the original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the original skb when local delivery is not needed. Either path can put the skb on an unresolved multicast route queue or forward it after the receive-side RCU section ends. After the prefetched socket is destroyed, a later skb free invokes sock_pfree() and dereferences the stale skb->sk. Orphan the skb before each non-local multicast forwarding path. Local delivery retains the original skb; the existing skb_clone() calls provide multicast forwarding with a socket-free clone.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89561", "url": "https://ubuntu.com/security/CVE-2026-89561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled. When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL. Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200: BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070 Read of size 4 at addr 00000000000006b4 by task ping6/394 CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full) Call Trace: kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup. Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89799", "url": "https://ubuntu.com/security/CVE-2026-89799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in bpf_get_stackid The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer. Note the bpf_get_stackid_pe function is executed already with preemption disabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89572", "url": "https://ubuntu.com/security/CVE-2026-89572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix OPP table cleanup apple_soc_cpufreq_init() adds OPP tables from firmware, but some failure paths do not remove them. The driver also uses dev_pm_opp_remove_all_dynamic(), which is not the right cleanup helper for OPP tables loaded from firmware. Use the cpumask OPP helper after the policy CPU mask has been populated. Pair it with the matching cpumask remove helper on failure paths and in apple_soc_cpufreq_exit(). This also removes the separate dev_pm_opp_set_sharing_cpus() call, as the cpumask helper loads the DT OPP tables for all CPUs in the policy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90037", "url": "https://ubuntu.com/security/CVE-2026-90037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during close_lru reaping An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.", "cve_priority": "critical", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90036", "url": "https://ubuntu.com/security/CVE-2026-90036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during blocked-lock reaping A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89622", "url": "https://ubuntu.com/security/CVE-2026-89622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in mcp->rxbuf for the duration of a transfer but never clears it when the transfer finishes or times out. Once the caller frees or reuses the buffer, mcp->rxbuf becomes a dangling pointer. A delayed or spurious MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to memcpy device data into the freed memory, causing a write use-after-free. Route all return paths through a single exit point that clears mcp->rxbuf and mcp->rxbuf_size, so that the existing !mcp->rxbuf guard in the raw_event handler can reject any report arriving after the transfer has ended.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90041", "url": "https://ubuntu.com/security/CVE-2026-90041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: clean up device list on probe failure sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory. Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim. Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89624", "url": "https://ubuntu.com/security/CVE-2026-89624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: universal-pidff: stop the device when force-feedback init fails universal_pidff_probe() starts the device with hid_hw_start() and then, if force-feedback initialisation fails, returns the error through a label that only does \"return error\". The device is left started. The HID core does not unwind on the driver's behalf. __hid_device_probe() releases the devres group, closes the report and clears hdev->driver: \tif (ret) { \t\tdevres_release_group(&hdev->dev, hdev->devres_group_id); \t\thid_close_report(hdev); \t\thdev->driver = NULL; \t} The hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added with cdev_device_add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid_device_remove() skips hid_hw_stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths. Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid_pidff_init_with_quirks() - no output reports, an allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, input_ff_create() - all reach the same label. Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do this. The two earlier gotos must keep returning without hid_hw_stop(), since neither has a started device, so give the path that fails after the start its own label. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89625", "url": "https://ubuntu.com/security/CVE-2026-89625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb(): \ttimer_delete_sync(&sc->ghl_poke_timer); \tusb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <- hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89644", "url": "https://ubuntu.com/security/CVE-2026-89644", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map leak in NOCOW direct I/O write btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an extent map reference that must be dropped on all exit paths. For direct writes into a NOCOW range, btrfs_get_blocks_direct_write() keeps using that extent map and asks btrfs_create_dio_extent() to allocate the ordered extent. If that fails, for example because btrfs_alloc_ordered_extent() fails, the function returns the error without dropping the input extent map. The PREALLOC path avoided this by dropping the input extent map before replacing it with the newly created one. Check the error from btrfs_create_dio_extent() before replacing the map and drop the input extent map on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90042", "url": "https://ubuntu.com/security/CVE-2026-90042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: properly decrypt filenames in vmalloc() buffers The fscrypt subsystem uses the scatterlist crypto API, inheriting its requirement that any buffers are in the linear mapping region. However, the messenger client uses kvmalloc() to create buffers for messages, which will occasionally place those buffers in the vmalloc() region when physical memory fragmentation doesn't permit a large enough kmalloc(). The various callers of ceph_fname_to_usr() directly pass (slices of) raw messages from the MDS without considering that the messages may be in vmalloc() buffers, resulting in oopses especially on non-x86 platforms (see 'Closes:' for more details and a reproducer). Make ceph_fname_to_usr() explicitly tolerant of vmalloc()-allocated fname->ctext, fname->name, and/or oname->name buffers, using `tname` (which, when non-null, must be a linear address; when null, is briefly allocated as necessary) as a bounce buffer to avoid passing any inappropriate addresses to fscrypt_fname_disk_to_usr(). Additionally change parse_reply_info_readdir() -- the only function to supply its own `tname` -- to follow the new \"tname must never come from vmalloc()\" rule by passing NULL when the message is not in the linear region. Though this causes a per-dentry kmalloc()+kfree(), this overhead exists only when processing the minority of messages that spill into vmalloc(). My (crude) testing puts this at only about 1 in 8,000 readdir messages. Still, if the overhead proves unreasonable in the future, it is easy enough to mitigate: a future change could allocate a bounce buffer in parse_reply_info_readdir() and use that as `tname` instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89659", "url": "https://ubuntu.com/security/CVE-2026-89659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during delegation revoke A delegation stateid holds only a bare pointer to its owning nfs4_client and does not keep it alive. The client survives its stateids only because __destroy_client() drains cl_delegations and cl_revoked before free_client() runs. nfs4_laundromat() breaks that invariant: it unhashes an expired delegation from cl_delegations, drops deleg_lock, then revoke_delegation() relinks it onto cl_revoked under cl_lock. In that window the delegation is on neither list, so client_has_state() can report no remaining state. Every teardown path first requires cl_rpc_users to be zero, but the laundromat holds no such reference. A client whose recalled delegation has just timed out can therefore reach free_client() while revoke_delegation() is still about to dereference cl_lock, a use-after-free. Pin the client with cl_rpc_users across the revoke so teardown blocks until it completes, then reap the delegation from cl_revoked. A client already expiring reaps its own, so skip it and leave the delegation on del_recall_lru.", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89676", "url": "https://ubuntu.com/security/CVE-2026-89676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix stale s2s_cp_stateids IDR entry for async COPY For an async COPY, nfsd4_copy() called nfs4_init_copy_state() before dup_copy_fields(), so the s2s_cp_stateids IDR was pointed at &u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is reused by the next request. dup_copy_fields() copies only the value into async_copy, so the IDR slot dangled at the transient buffer for the whole background copy. Any IDR walker then dereferences reused request memory: the laundromat reads cs_type from it and, if the bytes look like an expired NFS4_COPYNOTIFY_STID, follows into refcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has the same exposure via idr_find(). Duplicate the fields first, then register the stateid on the stable async_copy. result->cb_stateid is unchanged.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89685", "url": "https://ubuntu.com/security/CVE-2026-89685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix clock domain mismatch in clients_still_reclaiming() clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline. This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients. Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89708", "url": "https://ubuntu.com/security/CVE-2026-89708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown After a DESTROY_SESSION the per-session teardown path can free a session while rpciod still holds an inflight callback rpc_task that dereferences clp->cl_cb_session. nfsd4_probe_callback_sync() flushes cl_callback_wq, but once nfsd4_run_cb_work() has called rpc_call_async() the rpc_task lives on rpciod; flushing the workqueue does not wait for it. rpc_shutdown_client() does drain rpciod tasks, but uses a 1-second wait_event_timeout — tasks stuck in rpc_delay() (e.g. 2-second NFS4ERR_DELAY retries) can outlive the drain. destroy path rpciod ------------ ------ unhash_session(ses) nfsd4_probe_callback_sync(clp) flush_workqueue(cl_callback_wq) /* returns; rpc_task still live */ nfsd4_put_session_locked(ses) free_session(ses) -> kfree(ses) nfsd4_cb_sequence_done() reads cb_clp->cl_cb_session /* freed slab */ A second window exists in nfsd4_process_cb_update(). When __nfsd4_find_backchannel() returns NULL because unhash_session() has already removed the destroyed session from cl_sessions, setup_callback_client() takes the v4.1 early return so clp->cl_cb_session = ses never fires and the field retains a pointer to the about-to-be-freed session. Fix both by converting cl_cb_session to an RCU-protected pointer: - Move the cl_cb_session = ses assignment in setup_callback_client() to after rpc_create() succeeds, so it is only published when a working backchannel exists. Clear cl_cb_session on the error return in nfsd4_process_cb_update(). Both stores use rcu_assign_pointer(). - Annotate cl_cb_session with __rcu. All rpciod-side readers use rcu_read_lock()/rcu_dereference() and check for NULL, bailing to the appropriate error or requeue path: encode_cb_sequence4args(), decode_cb_sequence4resok(), nfsd41_cb_get_slot(), nfsd41_cb_release_slot(), nfsd4_cb_prepare(), and nfsd4_cb_sequence_done(). - Switch __free_session() from kfree() to kfree_rcu() so the session slab is not reclaimed until after an RCU grace period, guaranteeing that rpciod readers inside rcu_read_lock() never dereference freed memory. - Pass the session pointer to the nfsd_cb_seq_status and nfsd_cb_free_slot tracepoints instead of having them re-read cl_cb_session. - nfsd4_cb_prepare() calls rpc_exit() when the session is NULL, routing through the done/release path to requeue the callback.", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89698", "url": "https://ubuntu.com/security/CVE-2026-89698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage struct nfsd_genl_rqstp declares rq_daddr and rq_saddr as plain \"struct sockaddr\" (16 bytes). When an IPv6 NFS client is connected, nfsd_genl_rpc_status_compose_msg() casts these fields to \"struct sockaddr_in6 *\" (28 bytes) and reads sin6_addr at offset 8..24, which extends 8 bytes past the end of the 16-byte sockaddr field into the adjacent rq_flags member. The 16-byte nla_put_in6_addr then ships 8 bytes of truncated IPv6 address followed by 8 bytes of rq_flags to userspace via the NFSD_A_RPC_STATUS_SADDR6/DADDR6 netlink attributes. This is reachable by any unprivileged process in the network namespace because NFSD_CMD_RPC_STATUS_GET uses GENL_CMD_CAP_DUMP without GENL_ADMIN_PERM. Fix by widening rq_daddr and rq_saddr to struct sockaddr_storage so the IPv6 casts operate within bounds, copying sizeof(struct sockaddr_storage) bytes in the memcpy calls so the full address is captured, and zero-initializing the genl_rqstp stack variable to prevent leaking uninitialized tail bytes through netlink.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2025-40210", "url": "https://ubuntu.com/security/CVE-2025-40210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"NFSD: Remove the cap on number of operations per NFSv4 COMPOUND\" I've found that pynfs COMP6 now leaves the connection or lease in a strange state, which causes CLOSE9 to hang indefinitely. I've dug into it a little, but I haven't been able to root-cause it yet. However, I bisected to commit 48aab1606fa8 (\"NFSD: Remove the cap on number of operations per NFSv4 COMPOUND\"). Tianshuo Han also reports a potential vulnerability when decoding an NFSv4 COMPOUND. An attacker can place an arbitrarily large op count in the COMPOUND header, which results in: [ 51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 when NFSD attempts to allocate the COMPOUND op array. Let's restore the operation-per-COMPOUND limit, but increased to 200 for now.", "cve_priority": "high", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2026-89693", "url": "https://ubuntu.com/security/CVE-2026-89693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create() nfsd4_create() stores the return value of nfsd4_acl_to_attr() in status, but the switch(create->cr_type) block unconditionally overwrites it in every branch. ACL translation errors are silently discarded, and the CREATE proceeds without the requested ACL. Add an early exit check after nfsd4_acl_to_attr(), matching the pattern already used in nfsd4_setattr(). [ cel: prefer NFS4ERR_BADTYPE over NFS4ERR_ATTRNOTSUPP ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89717", "url": "https://ubuntu.com/security/CVE-2026-89717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: set default primary compressor in zram_destroy_comps() Patch series \"zram: fix zram issues reported by sashiko\". Sashiko drove by and reported [1] a couple of zram issues: a possible BUG_ON() in zlib code due to missing winbits range validation and one possible NULL-ptr dereference in zcomp. Both are low risk yet still worth fixing. This patch (of 2): zram_destroy_comps() resets all compressors and leaves them set to NULL, including the primary one, which is invalid device state, as now comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set default primary compressor in zram_destroy_comps().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89718", "url": "https://ubuntu.com/security/CVE-2026-89718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in writeback_store() Patch series \"zram: fix stale scan bounds after reinitialization\". Both writeback_store() and read_block_state() derive their table scan bounds from zram->disksize before acquiring dev_lock. If the device is reset and reinitialized with a smaller disksize between that read and lock acquisition, the bound can describe the old table while the scan operates on the new one. This can lead to out-of-bounds slot accesses. Move both bound calculations under dev_lock so each bound remains consistent with the table throughout its scan. Keep the fixes separate because the affected interfaces originate from different commits and can be backported independently. This patch (of 2): writeback_store() calculates the table scan bounds before taking dev_lock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writeback_store() is waiting for the lock. Once it acquires the lock, it sees an initialized device but scans the new table using the old upper bound, resulting in an out-of-bounds access. Calculate the number of pages while holding dev_lock so the scan bound matches the table protected by the lock.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89719", "url": "https://ubuntu.com/security/CVE-2026-89719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in read_block_state() read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-90044", "url": "https://ubuntu.com/security/CVE-2026-90044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix Use-After-Free in AIO error path In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`. If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer. To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window. We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90045", "url": "https://ubuntu.com/security/CVE-2026-90045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: ffs: fix mm lifetime handling io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending. This can result in a use-after-free if the task exits before completion handling finishes. Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89731", "url": "https://ubuntu.com/security/CVE-2026-89731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read cxl_rch_get_aer_info() copies the RCH Downstream Port AER capability from the RCRB MMIO block using a readl() loop bounded by sizeof(struct aer_capability_regs). This struct is a software layout and its embedded struct pcie_tlp_log is larger than the on-wire AER capability. As a result the loop reads past the mapped AER register block. The over-read also populates the software-only tail fields including header_log.header_len. An out-of-range header_len passed to pcie_print_tlp_log() can then loop past the header log buffer and cause a second out-of-bounds read. The read was correct when introduced, but struct pcie_tlp_log has since grown (Header Log and TLP Prefix Log sizes, header_len and flit fields), so sizeof(struct aer_capability_regs) no longer matches the physical AER capability. Bound the read to the physical AER registers, header through the 16 byte Header Log. Zero the destination first so the software-only fields are deterministic.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89755", "url": "https://ubuntu.com/security/CVE-2026-89755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: clear stale mapping after freeing swapcache __migrate_device_pages() reads the folio mapping before calling folio_free_swap(). When folio_free_swap() succeeds, the folio is removed from the swap cache, but the saved mapping still points to swap_space. Passing the stale mapping to folio_migrate_mapping() makes it use the mapped-folio path for a folio that is no longer in swapcache. It can then operate on swap_space.i_pages with invalid reference accounting, eventually triggering a folio reference count BUG. After a successful split, nr still contains the number of pages in the original large folio, although each resulting page is now a separate order-0 folio. Reset nr to 1 so each split folio is processed separately, including its own swapcache removal and mapping lookup. Refresh the saved mapping after folio_free_swap() so the current folio state is used during migration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89763", "url": "https://ubuntu.com/security/CVE-2026-89763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM teardown ordering trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown. The current order permits this interleaving: CPU 0 CPU 1 trusted_tpm_exit() key_type_lookup(\"trusted\") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., digests) CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it. KASAN reported: BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510 Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-80945", "url": "https://ubuntu.com/security/CVE-2026-80945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - unmap dst before software fallback on decompress On a hardware analytics error, decompress retries through the software fallback, which writes req->dst with the CPU while it is still mapped DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the stale bounce buffer over req->dst, corrupting the result. Unmap before the fallback runs. The async path unmaps inline; the sync path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the fallback after unmapping.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80847", "url": "https://ubuntu.com/security/CVE-2026-80847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clamp route advmss to TCP_MIN_MSS tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption. A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the \"default advmss\" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss. Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-97545", "url": "https://ubuntu.com/security/CVE-2026-97545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails LOLLM observes that in xfs_btree_bload_prep_block, xfs_btree_bload_drop_buf can hit an IO error if writing the delwri buffer list to disk fails. In this case, we fail to release new_bp, which means we lose a locked buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97552", "url": "https://ubuntu.com/security/CVE-2026-97552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: initialise error in xfs_defer_finish_one() xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the \"Done with the dfp, free it\" path, and the function returns an indeterminate value. An item-less pending item reaches this through xfs_defer_add_barrier(), which xfs_reap_ag_blocks() uses on any CONFIG_XFS_ONLINE_REPAIR kernel. xfs_defer_finish_noroll() treats any non-EAGAIN return as fatal, so a non-zero stack value turns a successful barrier into a SHUTDOWN_CORRUPT_INCORE in the middle of a repair. Zero is the correct result: reaching the free path means the item loop drained without a non-zero error.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97583", "url": "https://ubuntu.com/security/CVE-2026-97583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Clear stale peer app data after address list changes afs_fs_probe_fileserver() fetches the current endpoint state under server->fs_lock, but leaves old_alist as NULL. Consequently, afs_set_peer_appdata() treats every address list replacement as initial setup and only binds the new peers; it never unbinds peers removed from the old list. An address refresh can therefore proceed as follows. CPU 0 replaces server S's list and drops Pold without clearing Pold->app_data. The server destroyer then clears only S's current peers and lets S reach its RCU callback. After the callback frees S, CPU 1 handles a callback through an RxRPC connection that still pins Pold, reads Pold->app_data, and calls afs_use_server() on the freed object. KASAN reported: BUG: KASAN: slab-use-after-free in afs_find_server+0x3c/0xa0 Read of size 4 at addr ffff8881013e1af0 by task krxrpcio/7001/74 Call Trace: afs_find_server+0x3c/0xa0 afs_rx_new_call+0x15c/0x390 rxrpc_new_incoming_call+0x97c/0x1730 rxrpc_input_packet.constprop.0+0xd03/0xec0 rxrpc_io_thread+0x967/0x1640 Allocated by task 93: afs_lookup_server+0x1a7/0x14c0 afs_alloc_server_list+0x43f/0xb60 afs_create_volume+0x923/0x1490 afs_get_tree+0x1c6/0x10a0 Freed by task 0: kfree+0x131/0x3c0 rcu_core+0x50a/0x1850 Last potentially related work creation: __call_rcu_common.constprop.0+0x71/0xa10 afs_put_server+0x213/0x2b0 Preserve old->addresses for the peer app-data update so that removed peers are cleared before the endpoint state is replaced. Also advance both cursors when the old and new lists share a peer; activating the old/new comparison without this would otherwise loop forever on the shared entry.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97584", "url": "https://ubuntu.com/security/CVE-2026-97584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix incorrect free in candidate cleanup in afs_lookup_server() Fix afs_lookup_server() to not free an existing server's endpoint state when cleaning up a candidate server. The candidate record doesn't have an endpoint state yet at this point, so the free for that can just be removed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97587", "url": "https://ubuntu.com/security/CVE-2026-97587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: RISC-V: store available counter mask as bitmap The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong. Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough. [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97605", "url": "https://ubuntu.com/security/CVE-2026-97605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: preserve LZMA decoders on resize failure The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized. An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired. Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request. Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97606", "url": "https://ubuntu.com/security/CVE-2026-97606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: autofs: fix memory leak in autofs_fill_super() In autofs_fill_super(), we create a new inode using autofs_new_ino(), however, if we fail to create root_inode, (that is, root_inode failure path), we return -ENOMEM without freeing the new inode(ino) that we created causing a memory leak. Fix this by adding autofs_free_ino() to free the inode we created in root_inode failure path before returning ENOMEM.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97616", "url": "https://ubuntu.com/security/CVE-2026-97616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: release all action references on NEWACTION failure When a batched RTM_NEWACTION request replaces an existing action, tcf_idr_check_alloc() takes a temporary reference on it. If a later action fails to initialize, tcf_action_destroy() uses strict release semantics to clean up the actions initialized so far. For an action bound to a filter, the strict check returns -EPERM without dropping the temporary reference. This error also makes tcf_action_destroy() return before releasing subsequent entries. Any new action initialized between the bound action and the failing entry is leaked together with its reserved IDR slot, preventing reuse of its index. Use tcf_idr_release() to drop each reference held by the batch without rejecting bound actions. This allows cleanup to continue through all initialized entries and preserves the module reference release when an action is destroyed. Explicit action deletion and flushing retain their separate bind-count checks.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97902", "url": "https://ubuntu.com/security/CVE-2026-97902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: don't return -EINVAL for successful nested thaw Commit 7366f8b6fc6a (\"fs: handle freezing from multiple devices\") replaced the freeze_holders bitmask with per-holder counters to allow nested freezes. In the bitmask version, a thaw that released a shared hold while another holder remained returned 0. Since the rework, thaw_super_locked() drops the freeze reference via freeze_dec() but then returns -EINVAL when other freezers remain, misinforming the caller: the thaw did succeed, the superblock just stays frozen for the remaining holders. This breaks bdev-initiated freezing. When a filesystem is frozen with FIFREEZE and additionally frozen via bdev_freeze() -- which nests by design, see fs_bdev_freeze() -- the subsequent bdev_thaw() receives -EINVAL from the holder op although its freeze reference was dropped, and therefore keeps bd_fsfreeze_count elevated. Then device-mapper's unlock_fs() ignores bdev_thaw()'s return value, so nothing rebalances the count. After the user's FITHAW and umount, the block device can never be mounted again: dm-1: Can't mount, blockdev is frozen There is no way for userspace to drop the leaked count; only destroying the block device (or a reboot) recovers the device. Reproducer (any kernel since v6.8): dmsetup create dut --table \"0 $(blockdev --getsz \"$DEV\") linear $DEV 0\" mkfs.ext4 /dev/mapper/dut mount /dev/mapper/dut /mnt fsfreeze --freeze /mnt # freeze_ucount == 1 dmsetup suspend dut # bd_fsfreeze_count == 1, ucount == 2 dmsetup resume dut # ucount 2 -> 1, but thaw_super() # returns -EINVAL, so bdev_thaw() # keeps bd_fsfreeze_count at 1 fsfreeze --unfreeze /mnt # filesystem thaws fine umount /mnt mount /dev/mapper/dut /mnt # EBUSY, forever The same happens with fsfreeze held across an LVM snapshot of the origin volume. fs_bdev_thaw()'s documentation already describes the intended semantics: \"If this function returns zero it doesn't mean that the filesystem is unfrozen as it may have been frozen multiple times\". Restore them by returning 0 when a nested thaw drops its hold while other freezers remain. Thawing without holding a freeze still fails with -EINVAL as may_unfreeze() rejects that case before the reference count is touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97908", "url": "https://ubuntu.com/security/CVE-2026-97908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference. The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core. For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running. Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97915", "url": "https://ubuntu.com/security/CVE-2026-97915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Limit firmware log name prints to field size The name in struct vpu_tracing_buffer_header is a fixed-size array populated by the NPU firmware. It is expected to be NUL-terminated, but nothing on the host side enforces this, so printing it with an unbounded string conversion would read past the field if the terminator is ever missing and expose adjacent bytes of the shared tracing BO through dmesg and the debugfs FW log output. Print at most as many characters as the name field holds, so the output never runs past it even if the string is not NUL-terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97916", "url": "https://ubuntu.com/security/CVE-2026-97916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate firmware log buffer metadata The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc instead of re-reading them from the shared struct.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97917", "url": "https://ubuntu.com/security/CVE-2026-97917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr Add a size parameter to ivpu_to_cpu_addr() and validate that the whole [vpu_addr, vpu_addr + size) range stays within the BO.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97929", "url": "https://ubuntu.com/security/CVE-2026-97929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: validate URB actual_length in interrupt callback i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length. A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array. Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97953", "url": "https://ubuntu.com/security/CVE-2026-97953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TX descriptor availability check for TSO traffic stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: \t(skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97961", "url": "https://ubuntu.com/security/CVE-2026-97961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Allow list_del during perf_event_overflow() A PMU might use perf_sched_cb_inc() and perf_sched_cb_dec() interface to get the PMU call back function pmu::sched_task invoked at schedule in and schedule out. This is achieved by walking along the list anchored by sched_cb_list. The following scenario might lead to a list corruption. perf_pmu_sched_task() for_each_list_entry(..., &sched_cb_list) +--> __perf_pmu_sched_task() +--> event->pmu->sched_task()) +--> PMU_push_sample() +--> perf_event_overflow() +--> __perf_event_overflow() +--> pmu->stop() +--> perf_sched_cb_dec() remove entry from sched_cb_list while list node in use. This happens when ioctl(fd, PERF_EVENT_IOC_REFRESH, xxx) has been invoked and perf_event::event_limit hits zero. Prevent the list corruption and convert for_each_list_entry() to for_each_list_entry_safe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97965", "url": "https://ubuntu.com/security/CVE-2026-97965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: initialize _md in vxlan_xmit_one() If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable: if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) { if (info->options_len < sizeof(*md)) goto drop; md = ip_tunnel_info_opts(info); } Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr(): if (vxflags & VXLAN_F_GBP) vxlan_build_gbp_hdr(vxh, md); Inside vxlan_build_gbp_hdr(), md->gbp is read: if (!md->gbp) return; gbp = (struct vxlanhdr_gbp *)vxh; ... if (md->gbp & VXLAN_GBP_DONT_LEARN) gbp->dont_learn = 1; If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire. Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97978", "url": "https://ubuntu.com/security/CVE-2026-97978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: ice: don't dereference pointers from TP_printk() After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 (\"tracing: Warn when an event dereferences a pointer in TP_printk()\"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97985", "url": "https://ubuntu.com/security/CVE-2026-97985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Update last skb marker in manage_oob(). Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb. In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK): socketpair(AF_UNIX, SOCK_STREAM, 0, sk); 1) skb -> OOB skb -> NULL send(sk[0], \"ab\", 2, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 2) skb -> consumed OOB skb -> NULL send(sk[0], \"ab\", 2, MSG_OOB); recv(sk[1], buf, 1, MSG_OOB); recv(sk[1], buf, 0, MSG_PEEK); 3) consumed OOB skb -> OOB skb -> NULL send(sk[0], \"a\", 1, MSG_OOB); recv(sk[1], buf, 0, MSG_OOB); send(sk[0], \"b\", 1, MSG_OOB); recv(sk[1], buf, 1, MSG_PEEK); Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called. However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb. Let's update @last in manage_oob(). For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked. Note that manage_oob() is inlined and no stack canary is added.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97992", "url": "https://ubuntu.com/security/CVE-2026-97992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: protect config_ctx from being freed under the config callback vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock: \tstruct eventfd_ctx *config_ctx = v->config_ctx; \tif (config_ctx) \t\teventfd_signal(config_ctx); VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context: \tswap(ctx, v->config_ctx); \tif (ctx) \t\teventfd_ctx_put(ctx); eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory. The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context. This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 (\"vhost-vdpa: fix use-after-free of v->config_ctx\"), which was about vhost_vdpa_config_put() leaving a stale pointer behind. Here the pointer is maintained correctly and it is the read side that is unprotected. With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default). VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold. vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for. A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds: BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993 Workqueue: vduse-irq vduse_dev_irq_inject Call Trace: native_queued_spin_lock_slowpath+0x97/0x5b0 _raw_spin_lock_irqsave+0xd4/0xe0 eventfd_signal_mask+0x69/0x120 vhost_vdpa_config_cb+0x34/0x50 vduse_dev_irq_inject+0x46/0x60 process_one_work+0x468/0x950 Allocated by task 2992: do_eventfd+0x50/0x200 __x64_sys_eventfd2+0x2e/0x40 Freed by task 2992: eventfd_ctx_put+0xb9/0xc0 vhost_vdpa_unlocked_ioctl+0x116c/0x2190 Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value. Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98018", "url": "https://ubuntu.com/security/CVE-2026-98018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: i3c: serialize probe with bus removal mctp_i3c_probe() drops busdevs_lock after finding the matching bus. A concurrent I3C_NOTIFY_BUS_REMOVE can then unregister and free the bus netdev before probe passes its private data to mctp_i3c_add_device(). The latter consequently adds a list node through a freed mbus pointer. Keep busdevs_lock held until the device has been added. This also satisfies the __must_hold annotation on mctp_i3c_add_device().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98021", "url": "https://ubuntu.com/security/CVE-2026-98021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: reject oversized tx_queue_len at netlink parse time rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with \"ip link add ... txqueuelen 500000\" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks. Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper \"integer out of range\" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it). Document the bound in the rt-link.yaml netlink spec. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn): ip link add v0 txqueuelen 500000 type veth peer name v1 -> on the fixed kernel this is rejected with -ERANGE (\"integer out of range\" extack) instead of installing an oversized tx_queue_len that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98028", "url": "https://ubuntu.com/security/CVE-2026-98028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: nfp: drop the replaced rule from the list when reprogramming fails nfp_net_fs_add() replaces an existing rule by deleting it from the hardware, decrementing nn->fs.count and programming the new one. If nfp_net_fs_add_hw() fails the old entry stays on nn->fs.list - only the success path reaches list_replace() - so the list is one longer than nn->fs.count, and it advertises a rule whose hardware entry has already been torn down. nn->fs.count is what ETHTOOL_GRXCLSRLCNT reports, so userspace then sizes its buffer one entry short of what the GRXCLSRLALL walk wants to write. That used to overwrite one u32 past the allocation; since the walk is bounded it is a permanent -EMSGSIZE instead, as nothing ever resyncs the counter.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98029", "url": "https://ubuntu.com/security/CVE-2026-98029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eth: nfp: bound the ntuple rule dump by the caller's buffer size nfp_net_get_fs_loc() dumps every entry of nn->fs.list into rule_locs[] without consulting cmd->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed flow steering rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Bail out with -EMSGSIZE when the buffer fills up, the way the other ntuple capable drivers do, and report how many locations were filled so a shrinking rule list does not leave the caller reading stale slots.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98037", "url": "https://ubuntu.com/security/CVE-2026-98037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject untrusted allocated-object pointers When the final RCU read-side critical section ends, a local kptr is demoted to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer to an object whose lifetime is no longer protected. type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with MEM_ALLOC as a live allocated object. In particular, a refcount-only local kptr never carries NON_OWN_REF, so it still passes the bpf_refcount_acquire() argument check after RCU protection ends. The kfunc can then dereference NULL or stale memory. Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since type_is_non_owning_ref() is based on the same predicate, graph kfunc arguments obey the same live-object requirement. Fault-protected reads of the demoted pointer remain valid: writes are already rejected, and read fixups use bpf_may_fault_on_deref() rather than this predicate. [ kkd: Rewrote commit log ]", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98039", "url": "https://ubuntu.com/security/CVE-2026-98039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Require MEM_PERCPU for percpu kptr stores map_kptr_match_type() treats perm_flags as the set of register type flags that a kptr field permits. Adding MEM_PERCPU to that set for BPF_KPTR_PERCPU does not require the source register to carry it, however. The subset test consequently accepts both a plain bpf_obj_new() allocation and a referenced kernel pointer into a __percpu_kptr map field. Loads from the field are always marked MEM_PERCPU. Consumers then treat the stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer helpers relocate it, and map teardown selects the per-CPU free path. A plain allocation can therefore provide an arbitrary kernel read/write, while a kernel pointer can be relocated into an invalid address or sent through a missing destructor. Require the source MEM_PERCPU flag to match the destination field kind. This preserves valid bpf_percpu_obj_new() stores and rejects both the program-BTF and kernel-BTF variants.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98041", "url": "https://ubuntu.com/security/CVE-2026-98041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Don't predict JMP32 pointer vs zero comparisons Consider the following program: r1 = map_value; /* low 32 bits are zero at runtime */ r6 = 0xdead000000000000; if w1 != 0 goto l1; l0: r1 += r6; r2 = *(u64 *)(r1 + 0); exit; l1: r6 = 0; goto l0; At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98054", "url": "https://ubuntu.com/security/CVE-2026-98054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Fix unbalanced module reference count strace_open() invokes try_module_get() which on success takes the module reference. If any follow up operation causes strace_open() to fail, the refcount shall be put down.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98056", "url": "https://ubuntu.com/security/CVE-2026-98056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: remove stale namespaces by NSID range during scan nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98081", "url": "https://ubuntu.com/security/CVE-2026-98081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: finish active block group cleanup if call_zone_finish() fails do_zone_finish() clears BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE before finishing the zones. If call_zone_finish() then fails it returned early, leaving the now inactive block group on fs_info->zone_active_bgs, leaking its reference, the BTRFS_FS_NEED_ZONE_FINISH waiters are never woken, and as its alloc_offset equals the zone capacity btrfs_zone_finish_one_bg() keeps selecting it, spinning btrfs_zoned_activate_one_bg(). Fall through to the cleanup on failure too and return the error, but keep the block group read-only as its zones are left inconsistent.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98097", "url": "https://ubuntu.com/security/CVE-2026-98097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Dont send random pad bytes in RESET/ACTIVATE messages The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer. Replace the strcpy(data, l->if_name) with memcpy() so that the pad bytes are actually written (l->if_name[] is zero padded) rather than sending random bytes from the skb to the remote system. Replace two other strcpy() with strscpy().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98103", "url": "https://ubuntu.com/security/CVE-2026-98103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igmp: convert struct ip_sf_list to RCU Commit 23d2b94043ca (\"igmp: Add ip_mc_list lock in ip_check_mc_rcu\") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions. However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()). When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock. Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c: 1. Add struct rcu_head to struct ip_sf_list and annotate sf_next, sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse im->sources locklessly with for_each_psf_rcu(), reading and writing counter fields with READ_ONCE() and WRITE_ONCE(). Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98107", "url": "https://ubuntu.com/security/CVE-2026-98107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs. However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent. Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded. Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see. Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98114", "url": "https://ubuntu.com/security/CVE-2026-98114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: propagate DACL parsing errors parse_dacl() silently accepts truncated ACEs and allocation failures, allowing set_info_sec() to continue with an incomplete ACL conversion. Return parsing and allocation errors to parse_sec_desc() so malformed security descriptors are rejected before inode attributes or ACL xattrs are updated.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98126", "url": "https://ubuntu.com/security/CVE-2026-98126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for zero range When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing the file to grow beyond the caller's file-size limit. Fix this by calling inode_newsize_ok() before sending the zero-range request when the operation would extend EOF. Reproducer, using a file on a CIFS mount: \tbash -c ' \t FILE=/mnt/cifs/repro \t trap \"\" SIGXFSZ \t ulimit -f 3072 \t truncate -s 2M \"$FILE\" \t fallocate --zero-range -o 0 -l 4M \"$FILE\" \t echo \"fallocate rc=$?\" \t stat -c \"file size=%s\" \"$FILE\" \t' Before this change, the operation succeeds despite the 3 MiB limit: \tfallocate rc=0 \tfile size=4194304 After this change, fallocate fails and leaves the file at 2 MiB.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98127", "url": "https://ubuntu.com/security/CVE-2026-98127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: \tbash -c ' \t\tFILE=/mnt/cifs/repro \t\ttrap \"\" SIGXFSZ \t\tulimit -f 3072\t\t# RLIMIT_FSIZE = 3 MiB \t\t# A regular write is stopped at 3 MiB. \t\tdd if=/dev/zero of=\"$FILE\" bs=1M count=4 status=none \t\tstat -c \"size after write: %s\" \"$FILE\" \t\t# Insert 2 MiB into a 2 MiB file. \t\ttruncate -s 2M \"$FILE\" \t\tfallocate -i -o 0 -l 2M \"$FILE\" \t\tstat -c \"size after insert: %s\" \"$FILE\" \t' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: \tdd: error writing '/mnt/cifs/repro': File too large \tsize after write: 3145728 \tsize after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: \tdd: error writing '/mnt/cifs/repro': File too large \tsize after write: 3145728 \tfallocate: fallocate failed: File too large \tsize after insert: 2097152", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98151", "url": "https://ubuntu.com/security/CVE-2026-98151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic Take the following unprivileged program as an example: \tr0 = bpf_map_lookup_elem(...)\t/* PTR_TO_MAP_VALUE, offset 0 */ \t... \t14: r0 += r1\t\t\t/* r1 is a bounded scalar */ \t15: r9 = r0 Loading it triggers a verifier warning from reg_bounds_sanity_check(): \tverifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out \tof sync with range bounds r64={.base=0x0, .size=0x0} \tr32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0) What happens: 1. Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new offset is computed into dst_reg's var_off and 32/64-bit ranges. 2. Because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync(). 3. On the unprivileged path, sanitize_ptr_alu() is called and, via sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path. 4. That snapshot is taken between step 2 and the final reg_bounds_sync(): at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning. var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent: 1. sync var_off and r32 before the snapshot so they match, or 2. leave r32 at its original (already consistent) value and blank it only after the snapshot. The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74735", "url": "https://ubuntu.com/security/CVE-2026-74735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: fix tunnel and session refcount leak on seq_file release In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls. However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed. Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-72438", "url": "https://ubuntu.com/security/CVE-2026-72438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending and barrier reference leaks on discard failures raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-68303", "url": "https://ubuntu.com/security/CVE-2026-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-93793", "url": "https://ubuntu.com/security/CVE-2026-93793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: validate TX_CMD response layout TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload. For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93796", "url": "https://ubuntu.com/security/CVE-2026-93796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: null RX pointers after free When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free(). The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93801", "url": "https://ubuntu.com/security/CVE-2026-93801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: zero-initialize stack-allocated cifs_open_info_data Stack-allocated cifs_open_info_data may contain random data. This can make some fields have wrong value if they are not set later.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93804", "url": "https://ubuntu.com/security/CVE-2026-93804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: ibss: wait for in-flight TX on disconnect While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues. Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93817", "url": "https://ubuntu.com/security/CVE-2026-93817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: Fix addr_filter_ranges lifetime Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93828", "url": "https://ubuntu.com/security/CVE-2026-93828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix handling of damaged volume in exfat_create_upcase_table() When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely. If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97412", "url": "https://ubuntu.com/security/CVE-2026-97412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: quiesce DMA before freeing resources pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97428", "url": "https://ubuntu.com/security/CVE-2026-97428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: harden FRU PIA parsing with bounded helpers Replace the open-coded TLV walk with fru_pia_advance() and fru_pia_copy_field() helpers that bound every read by the actual EEPROM data length, preventing out-of-bounds reads on truncated or malformed FRU data.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97473", "url": "https://ubuntu.com/security/CVE-2026-97473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() When topology_physical_package_id()/topology_logical_die_id() returns a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL) directly without freeing the rapl_package structure that was just allocated by kzalloc_obj(), leaking memory on every failed package addition. Use the existing err_free_package label so that the allocation is released on the error path.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97492", "url": "https://ubuntu.com/security/CVE-2026-97492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed In case reconfiguration of NAN fails, we call ieee80211_handle_reconfig_failure, that marks all interfaces as not in the driver. Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces is called to destroy all the interfaces. If we have any other interface but the NAN one, for example a BSS station, then when its state (links, stations) will be removed, we won't tell the driver about this, because we will think that the interfaces are not in the driver, and then drivers might remain with dangling pointers to objects like stations and links (at least for iwlwifi this is the case). ieee80211_handle_reconfig_failure is meant to be called after we cleaned up the state in the driver, there is no reason to call it for NAN reconfiguration failure. Fix the code to just warn in such a case, as we do in other error paths in reconfig where it is too complicated to rewind.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97494", "url": "https://ubuntu.com/security/CVE-2026-97494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer. Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97505", "url": "https://ubuntu.com/security/CVE-2026-97505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check. Resizing a BAR modifies PCI device configuration and can disrupt active drivers. After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups(). Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97514", "url": "https://ubuntu.com/security/CVE-2026-97514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Fix Reports from Kernel Lock Validator handle_dynamic_resolution change requires that the state_lock be acquired based on the lockdep_assert_held. However, the handle_dynamic_resolution_change call in initialize_sequence does not properly obtain the lock before calling. Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called while a lock is already held. Store off the fbc_buf_count then properly update control once lock has been freed.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97518", "url": "https://ubuntu.com/security/CVE-2026-97518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject duplicate wiphy cipher suite entries Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them. One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE. Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97520", "url": "https://ubuntu.com/security/CVE-2026-97520", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: move quota_init qc iterator increment Move qc++ from the loop body into the for-loop increment expression in gfs2_quota_init(). This keeps iterator progression explicit and avoids mixing pointer advance with duplicate-slot handling in the loop body.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-80836", "url": "https://ubuntu.com/security/CVE-2026-80836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - bound the akcipher result length virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read). Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80925", "url": "https://ubuntu.com/security/CVE-2026-80925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 (\"ipvlan: inherit needed_headroom and needed_tailroom from phy_dev\") cef51860becd (\"macvlan: inherit needed_headroom and needed_tailroom from lowerdev\")", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80841", "url": "https://ubuntu.com/security/CVE-2026-80841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: defer vmalloc TX_RING free until skbs finish AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping. tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement. Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap. Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq. After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain. Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80861", "url": "https://ubuntu.com/security/CVE-2026-80861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: bail out of setup if the controller is inaccessible xhci_gen_setup() locates the operational registers using the capability length read from the very first register: \txhci->op_regs = hcd->regs + \t\tHC_LENGTH(readl(&xhci->cap_regs->hc_capbase)); If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses: xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible xhci-pci-renesas 0005:08:00.0: xHCI Host Controller xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1 Unable to handle kernel paging request at virtual address ffff80030a770103 ESR = 0x0000000096000021 FSC = 0x21: alignment fault Internal error: Oops: 0000000096000021 [#1] SMP pc : xhci_halt [xhci_hcd] Call trace: xhci_halt xhci_gen_setup xhci_pci_setup usb_add_hcd usb_hcd_pci_probe xhci_pci_common_probe xhci_pci_renesas_probe This was hit with a Renesas uPD720201 that failed to power up (\"Unable to change power state from D3cold to D0, device inaccessible\") yet still reached the HCD probe path. Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2025-40097", "url": "https://ubuntu.com/security/CVE-2025-40097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix missing pointer check in hda_component_manager_init function The __component_match_add function may assign the 'matchptr' pointer the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced. The call stack leading to the error looks like this: hda_component_manager_init |-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign |-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereference Add IS_ERR() check to prevent the crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "low", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2026-52988", "url": "https://ubuntu.com/security/CVE-2026-52988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on.", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-98102", "url": "https://ubuntu.com/security/CVE-2026-98102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src() When removing a source filter whose count reaches zero, ip6_mc_del1_src() unlinks psf from pmc->mca_sources. If the filter was previously active, the code moved psf directly into pmc->mca_tomb by updating psf->sf_next. Because pmc->mca_sources is traversed locklessly under RCU (e.g. by ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mca_sources and improperly examine deleted tombstone entries. Fix this by allocating a new tombstone node for pmc->mca_tomb (as done in sf_setstate()) and retiring the original psf via kfree_rcu().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98101", "url": "https://ubuntu.com/security/CVE-2026-98101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source() pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths. ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array. Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries. Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter(). Also remove the now unused IP6_SFBLOCK macro.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97523", "url": "https://ubuntu.com/security/CVE-2026-97523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: close race between scheduler and state change The mptcp scheduler may race with subflow sockets state change: data transmission on the selected socket may fail and a later release could try to use mss_now reset to 0 for a divide operation. Address the issue by explicitly checking for the critical scenario.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97524", "url": "https://ubuntu.com/security/CVE-2026-97524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid unneeded actions on subflow reset Once in a blue moon, the mptcp receive path can recursively call mptcp_data_ready() via state change under unlucky error conditions, and then try to hold the data lock again. Break the recursion loop explicitly checking for the exceptional condition. Add a new flag instead of using an existing one like 'closing', to exit early in subflow_state_change(), and explicitly flush the RX queue at reset time. This avoids unneeded processing to check for available data -- calling get_mapping_status() and more on a dying subflow -- but also in error reporting and worker scheduling. Note that we must consume the currently peeked skb before invoking mptcp_dss_corruption to avoid consuming it again after the eventual reset has freed it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97522", "url": "https://ubuntu.com/security/CVE-2026-97522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix bad accounting in __mptcp_subflow_push_pending() If __subflow_push_pending() errors out we should avoid updating the copied byte counters, to avoid mismatch push call later on.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-74496", "url": "https://ubuntu.com/security/CVE-2026-74496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Fix use-after-free in fou_create() fou_create() publishes struct fou through sk_user_data before adding the new FOU port to the per-netns list. If fou_add_to_port_list() fails, the error path frees fou while it is still reachable through sk_user_data. A concurrent receive can then dereference the freed object in fou_from_sock(). This ordering issue was previously noted in the linked discussion. The failure is reachable when local port 0 is requested. Each socket binds to a different ephemeral port, but fou_cfg_cmp() compares the requested port 0 and reports -EALREADY once an entry already exists. Release the tunnel socket before freeing fou so sk_user_data is cleared first, and defer reclamation with kfree_rcu() to protect concurrent RCU readers. This matches the lifetime handling in fou_release().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-93286", "url": "https://ubuntu.com/security/CVE-2026-93286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: appletalk: fix NULL pointer dereference in aarp_send_ddp() aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast path without checking for NULL. When the device has no AppleTalk interface configured (dev->atalk_ptr == NULL), this leads to a NULL pointer dereference at the at->s_net access. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2)) Call Trace: atalk_sendmsg (net/appletalk/ddp.c:1715) __sys_sendto (net/socket.c:2265 (discriminator 1)) __x64_sys_sendto (net/socket.c:2272) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Add a NULL check consistent with the other callers of atalk_find_dev_addr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93287", "url": "https://ubuntu.com/security/CVE-2026-93287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97931", "url": "https://ubuntu.com/security/CVE-2026-97931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Prevent write upgrades for read mappings The hwdep mmap callback rejects read-buffer mappings that are initially writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ. A process that can open the hwdep node O_RDWR can later use mprotect() to make the mapping writable. The read allocation begins with struct usb_stream. Its read_size member is used by the fault handler to decide which pages belong to the read buffer. The read VMA intentionally remains expandable because pcm_usb_stream uses mremap() after reading that size. Changing read_size first can therefore map and access pages beyond the allocation. The same member is also consumed by usb_stream_free(), where changing it can make free_pages_exact() release pages outside the allocation. Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially writable VMA. This keeps the separate output-buffer mapping writable while preventing later permission upgrades.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97540", "url": "https://ubuntu.com/security/CVE-2026-97540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. Instead of keeping a side table for additional information, use driver_info field of the usb_device_id. The dynamic ID parsing code needs to be updated for this; convert it to just write to the reserved entry for dynamic ID and remove the weird loop.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97541", "url": "https://ubuntu.com/security/CVE-2026-97541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: don't store usb_device_id usb_device_id is not guaranteed to live longer than probe due to presence of dynamic ID. All information apart from driver_data can be easily retrieved from usb_device, so just store driver_data.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97539", "url": "https://ubuntu.com/security/CVE-2026-97539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xusbatm: don't rely on id table pointer arithmetic The current code is broken when dynamic ID is involved; in such cases usb_device_id parameter of probe lives on the heap and the pointer arithmetic will get an index that is wildly out of bound. xusbatm initialize the USB device IDs dynamically so it can just use driver_info too. Even with conversion, xusbatm still cannot support dynamic IDs, so also set no_dynamic_id.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97542", "url": "https://ubuntu.com/security/CVE-2026-97542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bail out on bitmap errors in xrep_agfl_fill LOLLM also points out that the xagb_bitmap_set call in xrep_agfl_fill can fail, but we don't check the result of xagb_bitmap_walk, so we silently drop the error and proceed with inconsistent incore data. That shouldn't be allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97555", "url": "https://ubuntu.com/security/CVE-2026-97555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix heap overflow in DACL owner/group rewrite When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smb_ace)). If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation. Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which covers the smb_acl header and room for every ACE at maximum SID size. This replaces the previous split logic that used dacl_ptr->size for cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid mounts: both paths can trigger the same rewrite and need the same headroom. KASAN reports this as: BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs] Write of size 4 at addr ffff8881a5e25374 by task chown/5298 ... The buggy address is located 0 bytes to the right of allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97556", "url": "https://ubuntu.com/security/CVE-2026-97556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid leaking refcount when cifs_sb_tlink() fails cifs_oplock_break() takes over the reference that cifs_queue_oplock_break() acquired when it queued the work, and drops it with _cifsFileInfo_put() once the break has been processed. Only in setups with \"-o multiuser\", cifs_sb_tlink() may fail, at which point cifs_oplock_break() returns without putting the file reference, mirroring the reference leak we already fixed in the companion patch to cifs_queue_oplock_break(). This would trigger a crash due to busy inodes on the next unmount: BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) Drop the reference on that path as well. Doing so before the out label mirrors the normal path, which also puts the reference before cifs_done_oplock_break(). Found by Sashiko code review. The failure path was not exercised at runtime.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97557", "url": "https://ubuntu.com/security/CVE-2026-97557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid leaking refcount in cifs_queue_oplock_break() cifs_queue_oplock_break() unconditionally takes a reference on the target file before queueing cifs_oplock_break(). Only that work item decreases the reference counter again. If another oplock break arrives while that work is still queued, queue_work() will return false and not queue this second work item. As a result, we will never reach the point to drop the file reference again and are leaking this reference. This can be triggered when interacting with a slow-responding server. As a result, later unmount operations for this file system will fail with BUG: Dentry ... still in use (1) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) kernel BUG at fs/super.c:777! Fix this by only incrementing the reference count if the work has been queued successfully. Taking it after queue_work() is safe because all three callers hold tcon->open_file_lock across the call and _cifsFileInfo_put() decrements under that same lock, so a worker that starts the handler in the window cannot drop the reference before it has been taken.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97560", "url": "https://ubuntu.com/security/CVE-2026-97560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix one-byte OOB read in smb2_parse_native_symlink() When parsing a share-root relative native symlink, memcpy copies smb_target+1 (skipping the leading separator) but uses strlen(smb_target)+1 as the length, reading one byte past the allocated buffer. This fixes the following KASAN splat when accessing an SMB symlink with a target of '\\a\\b': BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0 Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1 CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N 7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996) Call Trace: dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 smb2_parse_native_symlink+0x4f5/0xca0 parse_reparse_point+0x68a/0x1530 reparse_info_to_fattr+0x752/0xa20 cifs_get_fattr+0x873/0x15b0 cifs_get_inode_info+0xc0/0x310 cifs_lookup+0x308/0xa70 __lookup_slow+0x122/0x2b0 lookup_slow+0x50/0x70 path_lookupat+0x525/0xaf0 filename_lookup+0x1f2/0x550 vfs_statx+0xd1/0x1a0 vfs_fstatat+0x65/0xc0 __do_sys_newfstatat+0x9a/0x120 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97562", "url": "https://ubuntu.com/security/CVE-2026-97562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: pin DFS superblock in iterator callback tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it. A deterministic KASAN test reproduces the race as: BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80 The same test passes with this change applied. Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97564", "url": "https://ubuntu.com/security/CVE-2026-97564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.idmap descriptions cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in \"os:\"/\"gs:\"/\"oi:\"/\"gi:\" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc (\"smb: client: reject userspace cifs.spnego descriptions\"), which applied the same restriction to cifs.spnego.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97568", "url": "https://ubuntu.com/security/CVE-2026-97568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: syncookies: remember the request backup flag Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97572", "url": "https://ubuntu.com/security/CVE-2026-97572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Propagate RX ring init failures in bnxt_init_nic() bnxt_init_rx_rings() returns an error when bnxt_alloc_one_rx_ring() fails, but bnxt_init_nic() discards that return value and calls bnxt_init_chip(), which enables TPA. If an allocation fails, this could leave rxr->rx_tpa[] partially zeroed and TPA would be enabled over an array with zeroed entries. This would lead to a zeroed DMA address being handed out if the agg_idx is translated to a SW index at a zeroed entry. Fix this by propagating the error out of bnxt_init_nic(). Both callers already check its return value and unwind with bnxt_free_skbs() and bnxt_free_mem(), which tolerate a partially initialized RX ring.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97573", "url": "https://ubuntu.com/security/CVE-2026-97573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset() bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97575", "url": "https://ubuntu.com/security/CVE-2026-97575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate AV1 tile counts The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97576", "url": "https://ubuntu.com/security/CVE-2026-97576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC tile counts The stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from column_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[] and use them as tile-loop bounds, but std_validate_compound() does not bound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling enabled whose tile counts exceed the uAPI array capacity, mirroring the existing compound-control range checks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97577", "url": "https://ubuntu.com/security/CVE-2026-97577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: rockchip: reject AV1 frames exceeding the tile capacity rockchip_vpu981_av1_dec_set_tile_info() indexes the tile group entry array by tile1 * tile_cols + tile0, reading up to tile_cols * tile_rows entries, lays out one descriptor per tile in the AV1_MAX_TILES tile_info buffer, and programs the real tile_cols / tile_rows into the hardware. The tile group entry control is a dynamic array sized to the number of entries userspace submitted, independent of tile_cols / tile_rows, so a frame that claims more tiles than entries reads past the array. A frame that claims more than AV1_MAX_TILES tiles also leaves the hardware programmed for more tiles than the descriptor buffer holds. Reject both in prepare_run(): tile_cols * tile_rows must not exceed the submitted entry count or AV1_MAX_TILES. The entry count is read via v4l2_ctrl_find() (ctrl->elems). This mirrors the bound the mediatek AV1 decoder already enforces.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97578", "url": "https://ubuntu.com/security/CVE-2026-97578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer rockchip_vpu981_av1_dec_set_tile_info() divides context_update_tile_id by tile_info->tile_cols and writes one descriptor per tile into the tile_info DMA buffer, which holds AV1_MAX_TILES entries; tile_cols and tile_rows come from the bitstream. Guard the division against a zero tile_cols by initialising the context-update values to zero and computing them only when tile_cols is non-zero, and stop the descriptor writes once the tile_info buffer is full. The tile geometry written to the hardware registers is left unmodified; the per-dimension and total tile bounds are enforced by the control validation.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97579", "url": "https://ubuntu.com/security/CVE-2026-97579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity vdec_av1_slice_setup_tile() copies tile_cols + 1 / tile_rows + 1 entries into mi_col_starts[] / mi_row_starts[] from the bitstream tile_info. Bound the copy to the array capacity.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97581", "url": "https://ubuntu.com/security/CVE-2026-97581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer capacity prepare_tile_info_buffer() writes one entry per tile into the tile_sizes DMA buffer, sized for a grid equal to the PPS uAPI array capacity. Use the bounded v4l2_hevc_pps_num_tile_columns() / v4l2_hevc_pps_num_tile_rows() helpers so the loops stay inside the buffer.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97582", "url": "https://ubuntu.com/security/CVE-2026-97582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gpio-fan) Fix use-after-free in alarm work fan_alarm_irq_handler() queues fan_data->alarm_work, but nothing cancels it. fan_alarm_notify() dereferences fan_data and its hwmon device. On unbind, devres frees the interrupt, which only waits for the handler itself, and then releases the hwmon device and fan_data, so a pending fan_alarm_notify() can run after those frees. Replace INIT_WORK() with devm_work_autocancel(), registered before devm_request_irq(). The devres cleanup then frees the interrupt first, so no new work can be queued, and cancels the work while fan_data and the hwmon device are still alive. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97592", "url": "https://ubuntu.com/security/CVE-2026-97592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm In function ctr_aes_crypt() there is a buffer used to process remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and thus could lead to expose of unwanted data. When the buffer is used explicitly scrub it at the end of the code block to avoid exposure of maybe sensitive data. In a similar way the function gcm_aes_crypt() hat an error path where the CPACF param block was not scrubbed. Instead of return early now these error paths go to end of function where explicit scrubbing is done. Similar with the buffers which are part of the gcm_sg_walk structs from the variables gw_in and gw_out.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97595", "url": "https://ubuntu.com/security/CVE-2026-97595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix use-after-free of sdata via queued RX frames The RX softirq producer ieee802154_subif_frame() queues received beacon and MAC-command frames onto local->rx_beacon_list / rx_mac_cmd_list and schedules a process-context worker, storing a raw mac_pkt->sdata (and skb->dev == sdata->dev) with neither a reference nor any locking: - the lists have no lock: the softirq producer list_add_tail()s while the mac_wq worker list_del()s, so sibling interfaces on the same phy corrupt the list; - the workers dereference the interface after it may have been freed. mac802154_rx_mac_cmd_worker() touches mac_pkt->sdata directly, and mac802154_rx_beacon_worker() -> mac802154_process_beacon() dereferences skb->dev (== sdata->dev). Removing an interface frees its sdata (netdev_priv) while a queued frame still points at it, so a later worker run is a use-after-free. Reproduced under KASAN by flooding a victim interface with MAC command frames and removing it (the beacon path is the same class via skb->dev): BUG: KASAN: slab-use-after-free in mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] Read of size 4 at addr ffff888002f9ea18 by task kworker/u8:1/31 Workqueue: phy0-mac-cmds mac802154_rx_mac_cmd_worker [mac802154] Call Trace: mac802154_rx_mac_cmd_worker+0x463/0x630 [mac802154] process_one_work+0x611/0xe80 worker_thread+0x52e/0xdc0 kthread+0x30c/0x630 ret_from_fork+0x2fd/0x3e0 Fix both lists together: - add local->rx_lock and take it around every list access: the softirq producer (plain spin_lock, softirq context) and the workers and flush (spin_lock_bh, process context); - pin the interface for the lifetime of a queued frame with netdev_hold()/netdev_put(), so the worker can safely dereference sdata / skb->dev even while the interface is being removed; - dequeue under the lock at the head and loop-drain the whole list in the workers (they previously processed one frame per run and relied on a later enqueue to drain the rest); - drop not-yet-started frames of an interface before it is unregistered, from ieee802154_if_remove() (after the RCU grace period) and from the ieee802154_remove_interfaces() loop -- the latter is the whole-phy teardown path, which does not go through ieee802154_if_remove(). An in-flight worker that already dequeued a frame keeps its own netdev reference; unregister_netdevice() then waits it out in netdev_run_todo(), which runs at rtnl_unlock() (rtnl released) and after the interface has been closed, so it does not pin rtnl. A worker blocked in an association TX only delays that one interface's unregister (the usual \"waiting for %s to become free\"), it does not hold rtnl. netdev_hold() is used for this reason instead of a cancel_work_sync() under rtnl, which would block on the worker's unbounded MLME TX wait via ieee802154_sync_queue(). The mac-command worker additionally skips processing for a stopped interface (ieee802154_sdata_running()), avoiding a needless association response during teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97596", "url": "https://ubuntu.com/security/CVE-2026-97596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97598", "url": "https://ubuntu.com/security/CVE-2026-97598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: bound automatic table ID allocation fib_empty_table() probes every table ID from 1 until it finds a free one. IPv4 tables are stored in a 256-bucket hash table, so a dense set of IDs makes each probe walk a growing hash chain while RTNL is held. Automatic table assignment (\"ip rule ... table 0\") is an IPv4-only legacy path. Bound the automatically allocated ID to 4096 so the RTNL hold stays bounded, without changing lookups of explicitly specified table IDs. This changes user-visible behavior. A table-0 rule previously received the lowest free ID in 1..RT_TABLE_MAX (0xFFFFFFFF). After this patch the search stops at 4096 and the rule add fails with ENOBUFS if that range is fully occupied. Explicit table IDs above 4096 remain usable. The automatic path is unused in practice: it is IPv4-only, not documented by ip-rule, uncovered by kernel selftests, and both NetworkManager and systemd refuse table 0.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97599", "url": "https://ubuntu.com/security/CVE-2026-97599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: \tpib_old = rtnl_dereference(phy->pib); \t... \trcu_assign_pointer(phy->pib, pib); \tkfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference().", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97601", "url": "https://ubuntu.com/security/CVE-2026-97601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink TUNSETLINK allows a TUN device to change its link-layer type to ARPHRD_IEEE802154 without initializing ieee802154_ptr. lowpan_newlink() checks only the device type before dereferencing the pointer, so an RTM_NEWLINK request can trigger a NULL pointer dereference. Reject devices without ieee802154_ptr along with devices of the wrong type.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97602", "url": "https://ubuntu.com/security/CVE-2026-97602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: invalidate queues before flushing them fqdir_pre_exit() flushes the skbs from incomplete queues without changing their completion state. A fragment which found a queue before high_thresh was cleared can then acquire the queue lock and reuse stale reassembly metadata. A queue concurrently killed after fqdir->dead is set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while still holding its old skbs; skipping it because it is complete leaves those references behind until asynchronous fqdir teardown. For IPv6, stale metadata can make ip6_frag_reasm() use the old nhoffset with a new skb and access memory out of bounds. The resulting heap corruption can be leveraged for local privilege escalation when unprivileged network namespaces are available. Unflushed fragments can also keep conntrack references alive after the conntrack per-net cleanup point. Kill each incomplete queue, then flush every queue still owned by the dying rhashtable. HASH_DEAD identifies that ownership, while complete queues without it are already owned by another destroy path and must be left alone. Releasing a timer reference removed by inet_frag_kill() is deferred to inet_frag_putn(), after the queue lock is dropped. KASAN report: BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) Write of size 1 at addr ff110001039c6e00 by task poc/771 Call Trace: ? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00) BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) Read of size 1 at addr ff110001039c6e08 by task poc/771 Call Trace: ? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1)) ip6_input_finish (net/ipv6/ip6_input.c:534) ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3)) packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142) __x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880) The buggy address belongs to the object at ff110001039c6b40 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 8 bytes to the right of allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97604", "url": "https://ubuntu.com/security/CVE-2026-97604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97607", "url": "https://ubuntu.com/security/CVE-2026-97607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Put device on unsupported feature error Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97608", "url": "https://ubuntu.com/security/CVE-2026-97608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: unregister loggers before per-net teardown nf_log_syslog and nfnetlink_log unregister their per-network namespace operations before unregistering their global logger backends. This leaves a window where a sysctl or netlink writer can rebind the still- registered logger after the per-net pre-exit callback cleared the old selection. The race looks like this: CPU 0 CPU 1 ---- ---- unregister_pernet_subsys() nf_log_unset(net, logger) net->nf.nf_loggers[pf] = NULL lock nf_log_mutex find logger in loggers[][] net->nf.nf_loggers[pf] = logger unlock nf_log_mutex nf_log_unregister(logger) lock nf_log_mutex loggers[pf][type] = NULL unlock nf_log_mutex synchronize_rcu() module exit returns module core frees backend memory Later, a sysctl read or packet logging operation can dereference the stale per-net logger pointer. Fix this by unregistering the global logger backends before tearing down per-net state. Once the global registrations are gone, later writers can no longer rebind the logger. unregister_pernet_subsys() already waits for an RCU grace period after the pre-exit callback clears the per-net selection, while nf_log_unregister() continues to cover readers of the global logger table. Apply this ordering fix to both nf_log backends that combine per-net teardown with global logger registration.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97611", "url": "https://ubuntu.com/security/CVE-2026-97611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix use-after-free of the flow table mask array tbl_mask_array_realloc() retires the old mask_array before it stops being reachable: \told = ovsl_dereference(tbl->mask_array); \tif (old) { \t\t... \t\tcall_rcu(&old->rcu, mask_array_rcu_cb); \t} \trcu_assign_pointer(tbl->mask_array, new); call_rcu() only waits for read-side critical sections already in flight. tbl->mask_array still points at old between the call_rcu() and the rcu_assign_pointer(), so a reader entering ovs_flow_tbl_lookup_stats() in that window picks up old in a fresh critical section that the pending grace period does not cover. tbl_mask_array_realloc() runs in process context under ovs_mutex, so the window is preemptible and can outlast the grace period. Then mask_array_rcu_cb() frees old before the swap runs: BUG: KASAN: slab-use-after-free in flow_lookup.constprop.0+0x2bf/0x2f0 Read of size 8 at addr ffff888020b3e018 by task poc/741 flow_lookup.constprop.0+0x2bf/0x2f0 ovs_flow_tbl_lookup_stats+0x4a3/0x5c0 ovs_dp_process_packet+0x19c/0x710 ovs_vport_receive+0x243/0x390 internal_dev_xmit+0x81/0x170 Freed by task 728: kfree+0x16a/0x4e0 rcu_core+0x853/0x1030 Publish the new array before retiring the old one. The kfree_rcu() that call_rcu() replaced ran after the swap.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97612", "url": "https://ubuntu.com/security/CVE-2026-97612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: clear inner_protocol when the last label is popped skb_mpls_push() records the pre-encapsulation network header once, gated on !skb->inner_protocol. skb_mpls_pop() never clears that record, so it outlives the encapsulation it describes. Open vSwitch can then re-push MPLS onto a packet whose inner_network_header still points at the older, deeper offset: push a label, pop every label, recirculate (ovs_flow_key_update() re-derives key->eth.type and resets network_header, but leaves inner_*), then push again. ovs_fragment() trusts the record: \tskb->network_header = skb->inner_network_header; so skb_network_offset() goes negative. The bound check is signed: \tif (skb_network_offset(skb) > MAX_L2_LEN) a negative offset passes it, and prepare_frag() widens the value: \tunsigned int hlen = skb_network_offset(skb); \tmemcpy(&data->l2_data, skb->data, hlen); which is a ~4GiB memcpy out of a 30-byte per-CPU buffer. Reproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8): BUG: unable to handle page fault for address: ffffe8ffffc16000 #PF: supervisor write access in kernel mode Oops: 0002 [#1] SMP KASAN NOPTI RIP: 0010:memcpy+0x8/0x20 RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000 prepare_frag+0x3df/0x4e0 ovs_fragment+0x589/0x7e0 do_output+0x4ce/0x5e0 do_execute_actions+0x55d2/0x7b30 ovs_execute_actions+0xea/0x450 Same root-cause shape as commit 975b5b067f52 (\"ipv6: sr: restore network header before routing and forwarding\"): a stale network header offset reaching a consumer that widens it. Here it originates in the MPLS push/pop path. Clear inner_protocol once the packet is no longer MPLS, so a later push re-records the current header. net/sched/act_mpls.c is the only other skb_mpls_pop() caller and gets the same fix; sch_frag.c saves and restores inner_protocol around fragmentation in the same way OVS does.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97613", "url": "https://ubuntu.com/security/CVE-2026-97613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Reserve extra CQ slot for the fence completion CQE The RX completion queue is sized to hold exactly one CQE per posted RX WQE. MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after the packet CQEs. The current sizing reserves no extra slot for it and in rare cases, CQ has no guaranteed slot for the fence CQE when it is full of packet CQEs. This can lead to dropping the fence completion while the driver waits holding RTNL lock throughout the timeout duration. Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory() requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE; the reservation pushes cq_size past a power-of-two, so round up the CQ size in mana_create_rxq().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97899", "url": "https://ubuntu.com/security/CVE-2026-97899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix memory leak in query_perf_config_list() When krealloc() fails, free the original oa_config_ids before returning to avoid a memory leak. (cherry picked from commit 9977e9d84f46d4f12ad35fbbc0ec4638554bce87)", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97900", "url": "https://ubuntu.com/security/CVE-2026-97900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/drm_exec: fix up contended obj when num_objects is 0 drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97904", "url": "https://ubuntu.com/security/CVE-2026-97904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: initialize policy rwsem before sysfs publication cpufreq_policy_alloc() initializes policy->rwsem after kobject_init_and_add() has created the policy sysfs directory and its default attributes. A sysfs access can therefore reach a policy callback before the semaphore has been initialized. Initialize policy->rwsem before publishing the policy kobject so sysfs callbacks always see an initialized semaphore.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97905", "url": "https://ubuntu.com/security/CVE-2026-97905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: zero-initialize policy cpumask before sysfs publication cpufreq_policy_alloc() allocates policy->cpus with alloc_cpumask_var(), i.e. without __GFP_ZERO, unlike the sibling related_cpus and real_cpus masks. With CONFIG_CPUMASK_OFFSTACK=y the mask is a separate kmalloc_node() allocation, so its bitmap holds whatever the slab allocator left behind: cpufreq_online() cpufreq_policy_alloc() alloc_cpumask_var(&policy->cpus) /* bitmap is uninitialized */ kobject_init_and_add() /* policy%u/ appears in sysfs */ cpufreq_policy_online() cpumask_copy(policy->cpus, cpumask_of(cpu)) /* first valid value */ This leaves a window in which the sysfs attributes are already reachable while policy->cpus is still garbage. show()/store() gate on policy_is_inactive(), i.e. cpumask_empty(policy->cpus), so a non-zero bitmap makes them run the attribute callbacks on a policy that is not initialized yet. Fix this by using zalloc_cpumask_var() for policy->cpus.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97907", "url": "https://ubuntu.com/security/CVE-2026-97907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Don't leak return code when parsing firmware format v2 When key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally ignores all security headers. However, the implementation simply breaks from a switch statement and leaks uninitialized return code `rc' (if the first section is a security one) or the previous section's `rc'. Fix it by really skipping a loop with `continue'. For consistency and readability, also do the same for the default case.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97909", "url": "https://ubuntu.com/security/CVE-2026-97909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: initialize IRQ lock before requesting IRQ uni_reader_init() registers the shared IRQ before initializing reader->irq_lock. A pending interrupt can invoke the handler while the lock is still uninitialized. Initialize the lock before registering the IRQ so the interrupt path always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97910", "url": "https://ubuntu.com/security/CVE-2026-97910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: sprd: validate compress buffer sizes against fixed allocations sprd_platform_compr_open() allocates the stage 0 IRAM buffer (32K data area) and the stage 1 DDR buffer (2M data area) with fixed sizes, but sprd_platform_compr_copy() derives all copy lengths from the user controlled runtime->fragment_size and the write() count, never comparing them against the physical buffer sizes. The compress core only checks fragment_size * fragments for an u32 overflow in snd_compress_check_input(), so a local user can configure a logical buffer of up to ~4GB via SNDRV_COMPRESS_SET_PARAMS, far exceeding the fixed allocations. A fragment_size larger than the 32K IRAM data area makes the stage 0 copy_from_user() overflow past the IRAM allocation, and a buffer_size larger than the 2M DDR buffer makes the wrapping copy at the end of sprd_platform_compr_copy() write fully user controlled data past the buffer. No SNDRV_PCM_TRIGGER_START is needed, a write() in SETUP state reaches the copy callback directly. Reject parameters that do not fit into the fixed buffers in set_params(), and fix the advertised max fragment size: 128K never fitted into the 32K IRAM buffer. The caps values may have been carried over from the qdsp6 driver, which allocates its buffers according to the advertised maxima, unlike this driver. With 32K as max fragment size the advertised limits are self-consistent: 32K * 64 = 2M equals the DDR buffer size. Discovered by Atuin - Automated Vulnerability Discovery Engine.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97920", "url": "https://ubuntu.com/security/CVE-2026-97920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Keep the entry count when the histogram stats allocation fails print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: \tn_entries = tracing_map_sort_entries(map, ...); \tif (n_entries < 0) \t\treturn n_entries; \t... \t\t\tif (!stats) { \t\t\t\tn_entries = -ENOMEM; \t\t\t\tgoto out; \t\t\t} \t... out: \ttracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with \"tracing: hist: let values keep the percent and graph modifiers\", so it should be applied first.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97921", "url": "https://ubuntu.com/security/CVE-2026-97921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: \thist_field = parse_expr(hist_data, file, field_str, flags, var_name, \t\t\t\t&n_subexprs); \t... \tif (hist_field->flags & HIST_FIELD_FL_VAR) { \t\tif (hist_field->flags & (...)) \t\t\tgoto err; \t} else { \t\tif (hist_field->flags & (...)) \t\t\tgoto err; \t} \thist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e (\"tracing: Do not let histogram values have some modifiers\") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \\ \t events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97922", "url": "https://ubuntu.com/security/CVE-2026-97922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram var refs regardless of how often they are referenced Using the same variable three or more times in one hist trigger leaks the variable reference and its strings when the trigger is removed. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made a trigger's var_refs[] array the only owner of a var ref: destroy_hist_field() returns early for HIST_FIELD_FL_VAR_REF, so the field expressions never destroy one. One entry, freed once, no count needed. commit 8bcebc77e85f (\"tracing: Fix histogram code when expression has same var as value\") then made repeated references share one object and added a count of them. Only the increment side exists, since those expressions still return early and never drop a reference, so __destroy_hist_field() sees how many references were created rather than how many are left. It frees when the decremented count is 0 or 1, so two references work and three or more leak. Sharing kept one array entry per object, and create_var_ref() searches and appends within a single trigger, so nothing outside it holds the object. Removing a trigger whose variables are still referenced is already refused by check_var_refs() with -EBUSY. Drop the count and free unconditionally.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97923", "url": "https://ubuntu.com/security/CVE-2026-97923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the var ref when its initialization fails create_var_ref() allocates a VAR_REF hist_field and then calls init_var_ref() to fill it in. When that fails the field is leaked. commit 656fe2ba85e8 (\"tracing: Use hist trigger's var_ref array to destroy var_refs\") made destroy_hist_field() return early for HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's var_refs[] array instead. create_var_ref() adds the field to that array only after init_var_ref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroy_hist_field(). init_var_ref() cannot free it either. The caller owns the field, so init_var_ref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave create_var_ref() passing freed memory to destroy_hist_field(), which reads its flags. Call __destroy_hist_field(), which frees the field without consulting the flag.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97924", "url": "https://ubuntu.com/security/CVE-2026-97924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Don't destroy fields when event removal fails destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs. Move the field destruction after the call removal, and splice the field list back onto the event when the removal fails so the event remains in a consistent state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97925", "url": "https://ubuntu.com/security/CVE-2026-97925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tick/broadcast: Plug clockevents replacement race 朱恺乾 reported and decoded the following race condition when a broadcast device is replaced: CPUA\t\t\t\t\tCPUB __tick_broadcast_oneshot_control() bc = tick_broadcast_device.evtdev; \t\t\t\t\ttick_install_broadcast_device(dev) \t\t\t\tclockevents_exchange_device(cur, dev) \t\t\t\t\t shutdown(cur); \t\t\t\t\t detach(cur); \t\t\t\t\t cur->handler = noop; \t\t\t\t\t tick_broadcast_device.evtdev = dev; tick_broadcast_set_event(bc, next_event); <- FAIL: arms a detached device. If the original broadcast device has a restricted interrupt affinity mask and the last CPU in that mask goes offline then the BUG() in tick_cleanup_dead_cpu() triggers because the clockevent device is not in detached state. The reason for this is that tick_install_broadcast_device() is not serialized vs. tick broadcast operations. The obvious cure is to serialize tick_install_broadcast_device() with tick_broadcast_lock against a concurrent tick broadcast operation. That requires to split clockevents_exchange_device() into two parts, one which does the exchange, shutdown and detach operation and the other which drops the module reference count. This is required because the module reference cannot be dropped while holding tick_broadcast_lock. Let clockevents_exchange_device() do both operations as before, but let the broadcast device code take the two step approach and do the device exchange under tick_broadcast_lock and drop the module reference count after releasing it.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97926", "url": "https://ubuntu.com/security/CVE-2026-97926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: \tucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); \tucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); \tucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); \tucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: - c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. - c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97927", "url": "https://ubuntu.com/security/CVE-2026-97927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ufs: create the root dentry after loading cylinder metadata ufs_fill_super() installed sb->s_root before it loaded the cylinder group structures for a writable mount: \tsb->s_root = d_make_root(inode); \t... \tif (!sb_rdonly(sb)) \t\tif (!ufs_read_cylinder_structures(sb)) \t\t\tgoto failed; When ufs_read_cylinder_structures() failed, the error path freed the in-core superblock information and set sb->s_fs_info to NULL while sb->s_root stayed installed. get_tree_bdev() then reached deactivate_locked_super(), and because s_root was present, generic_shutdown_super() called sync_filesystem() and the put_super operation. Both dereference UFS_SB(sb), which is now NULL, so a mount that fails only while reading the cylinder groups oopses during teardown. A crafted image whose first cylinder group cannot be read reaches this path. Load the cylinder group metadata first and create the root dentry last, so the superblock is published to the VFS only once it is fully set up. ufs_setup_cstotal() and ufs_read_cylinder_structures() take only the super_block and do not use the root inode, so the reordering is safe.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97930", "url": "https://ubuntu.com/security/CVE-2026-97930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf The in04_last array in struct usx2ydev is declared as char[24], but in04_buf is allocated as sizeof(struct us428_ctls) which is 21 bytes. In i_usx2y_in04_int(), when ctl_snapshot_last == -2 (initialization path): memcpy(usx2y->in04_last, usx2y->in04_buf, sizeof(usx2y->in04_last)); This copies 24 bytes from a 21-byte slab allocation, reading 3 bytes past the end of the source object. Introduce a USX2Y_IN04_SIZE constant defined as sizeof(struct us428_ctls) and use it consistently for the in04_last array, the in04_buf allocation, the URB transfer length, and the comparison loop, replacing the bare 24 and 21 literals throughout.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97936", "url": "https://ubuntu.com/security/CVE-2026-97936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the \".stacktrace\" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: \tn_entries = *stack; \tmemcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, \"must be a long[] type\", so enforce it once the name has been resolved. Names which resolve to no field at all, \"hitcount.stacktrace\" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97940", "url": "https://ubuntu.com/security/CVE-2026-97940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route() can move a still-linked walker into that same state when the current leaf is the last route at the root, so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only widens the race.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97945", "url": "https://ubuntu.com/security/CVE-2026-97945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix user-space data loss with MADV_FREE and THP Some of users of Polars (a data analytics library) have lost production data from this bug. They seem to have just the right combination of huge pages, MADV_FREE and heavy reclaim pressure. pmd_modify() masks the old value with (_HPAGE_CHG_MASK & ~_PAGE_DIRTY), silently discarding the hardware dirty bit. The subsequent pmd_mksaveddirty() call is supposed to transfer _PAGE_DIRTY into _PAGE_SAVED_DIRTY when write-protecting, but the dirty bit was already stripped from the value, so there is nothing left to transfer. Contrast with pte_modify(), which keeps _PAGE_DIRTY_BITS in its mask, and pud_modify(), which keeps _HPAGE_CHG_MASK untouched: pmd_modify() is the odd one out. Any pmd_modify() on a writable, dirty PMD loses the dirty state. One visible consequence is data loss with MADV_FREE on PMD-mapped THP: memset(buf, 0x5A, size); // PMD-mapped THP, PMD dirty madvise(buf, size, MADV_FREE); // PMD cleaned but left writable, // folio marked lazyfree memset(buf, 0x5A, size); // hardware sets _PAGE_DIRTY again mprotect(buf, size, PROT_READ); // pmd_modify() drops the dirty bit mprotect(buf, size, PROT_READ|PROT_WRITE); // ... memory pressure ... Reclaim (e.g. under memcg pressure) then finds the lazyfree folio with no dirty bit set anywhere and frees it in __discard_anon_folio_pmd_locked(), even though the data was rewritten after MADV_FREE; subsequent reads fault in fresh zero pages. NUMA hinting alone can trigger the same loss, as do_huge_pmd_numa_page() restores the PMD through pmd_modify() as well. PMD-mapped file THPs are affected too: mprotect()/NUMA hinting dropping the dirty bit means rewritten data is never written back. Fix it by keeping _PAGE_DIRTY in the preserved mask, exactly like pte_modify() and pud_modify() do. The existing pmd_mksaveddirty()/pmd_clear_saveddirty() pair then performs the hardware-dirty <-> saved-dirty transition based on the write bit, preserving the shadow-stack encoding rules.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97948", "url": "https://ubuntu.com/security/CVE-2026-97948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver The commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug safe\") refactored the EEH code such that the pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken. [<0>] 0xc00000011c78f870 [<0>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18 The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no error handlers like slot_reset(), resume() etc defined).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89792", "url": "https://ubuntu.com/security/CVE-2026-89792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds reads in share config responses Validate IPC share configuration payload sizes before consuming variable-length fields. Bound veto list parsing and account for the separator byte when deriving the path length.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-97951", "url": "https://ubuntu.com/security/CVE-2026-97951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands When a LUN_RESET aborts a WRITE command that is in the TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits for the frontend to finish processing. If the initiator subsequently sends the remaining dataout PDUs, __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in target_put_cmd_and_wait(), leading to a deadlocked target worker thread. Fix this by explicitly calling target_complete_cmd() when the final dataout PDU is received for an aborted WRITE command. target_complete_cmd() detects the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work, allowing the abort completion to successfully unblock.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97952", "url": "https://ubuntu.com/security/CVE-2026-97952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunvdc: unmap LDC cookies when the descriptor send fails __send_request() maps the request's pages into the LDC channel's map table (ldc_map_sg()), fills in the descriptor and marks it VIO_DESC_READY before ringing the doorbell via __vdc_tx_trigger(). When the trigger fails, the error path only prints a message: the descriptor stays READY and the cookies are never unmapped. The mapping is normally released in vdc_end_one() when the peer completes the descriptor - but a descriptor whose doorbell was never sent will never complete, and since dr->prod is not advanced on failure, the reset path (vdc_requeue_inflight(), which walks [cons, prod)) never visits it either. The map table entries are leaked permanently. Since commit a11f6ca9aef9 (\"sunvdc: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN\") trigger failures occur in practice under load, so every resulting I/O error also leaks one request's worth of entries from the fixed-size (8192 entries per channel) map table. Because the allocator hands out contiguous ranges, fragmentation makes large multi-segment requests fail first as the table drains, until ldc_map_sg() fails permanently and the disk is dead until reboot. It also makes any retry-based recovery unusable: requeuing the request on -EAGAIN remaps the pages on every attempt, overwriting desc->cookies and orphaning the previous mapping, so the table drains at the retry rate. This is the memory exhaustion observed when the requeue approach was first tested in October 2025. Roll back on failure: unmap the cookies, mark the descriptor FREE again and clear the request entry. If the trigger failed with -ENOTCONN, __vdc_tx_trigger() has already reset the port, which tears down and reallocates both the dring and the LDC channel including its map table - nothing to roll back, and the stale descriptor must not be touched.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97954", "url": "https://ubuntu.com/security/CVE-2026-97954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix tcp stream corruption with large pages rds_message_map_pages() assigns PAGE_SIZE bytes to every scatterlist entry, even when total_len ends in a partial page. The RDS congestion map is defined as 8192 bytes, so on systems with PAGE_SIZE greater than 8192 the scatterlist maps bytes beyond the end of the congestion map. RDS-TCP transmits the SG contents according to those lengths, so the extra bytes become part of the TCP RDS stream and are interpreted as subsequent RDS message headers, corrupting the stream. Limit the final scatterlist mapping to the number of bytes remaining. This has no effect on systems with a 4K page size and allows RDS-TCP to be used on systems with 16K and larger page sizes. The RDS selftest, which previously hung on 16K pages, now passes.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97957", "url": "https://ubuntu.com/security/CVE-2026-97957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix mailbox segment buffer overflow check_mbox_seq_id_and_seg_len() validates that seq_id does not exceed SEQ_ID_MAX_VAL (42) and seg_len does not exceed MBOX_SEG_LEN (48). However, this allows the last segment (seq_id=42) to carry a full 48-byte payload, writing to offset 42*48=2016 for 48 bytes (ending at byte 2064). The receive buffer is only MBOX_MAX_BUF_SZ (2048) bytes, resulting in a 16-byte heap buffer overflow. The hinic3 driver already handles this correctly by defining MBOX_LAST_SEG_MAX_LEN and rejecting the last segment when it exceeds the remaining buffer space. Apply the same fix to the hinic driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97958", "url": "https://ubuntu.com/security/CVE-2026-97958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain(). If a netlink socket sends RTM_GETCHAIN requests repeatedly without recv()ing the responses, tc_ctl_chain() hogs CPU and triggers Hung Task splat. [0] As caught in the stack trace, netlink_attachskb() could confuse tc_ctl_chain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full. The replay: label exists since commit 32a4f5ecd738 (\"net: sched: introduce chain object to uapi\") but was not used initially. Since commit 9f407f1768d3 (\"net: sched: introduce chain templates\"), the label is needed for RTM_NEWCHAIN because tcf_proto_lookup_ops() may release RTNL to call request_module(). However, the replay logic is unnecessary for RTM_GETCHAIN. Let's apply the replay logic only for RTM_NEWCHAIN. [0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97959", "url": "https://ubuntu.com/security/CVE-2026-97959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: free emptied bucket on filter move route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \\ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \\ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97963", "url": "https://ubuntu.com/security/CVE-2026-97963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97964", "url": "https://ubuntu.com/security/CVE-2026-97964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_synctty: ensure a writeable skb header ppp_sync_txmunge() checks headroom before prepending the address and control bytes, but does not ensure that the skb header is writable. A received skb can reach this function through PPP channel bridging without passing through ppp_start_xmit(), which calls skb_cow_head(). For example, a PPPoE frame may share its buffer with a clone queued to an AF_PACKET socket. If it is bridged to a synchronous tty channel, the address/control bytes can overwrite data still visible to that socket. Use skb_cow_head() to ensure both sufficient headroom and a writable header.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97966", "url": "https://ubuntu.com/security/CVE-2026-97966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: reset HTB scheduler topology before freeing queues HTB offload programs NIX_AF_TLxX_TOPOLOGY on QoS-allocated scheduler queues via otx2_qos_txschq_set_parent_topology(), but teardown freed those queues without clearing TOPOLOGY. The AF only restores PARENT and SCHEDULE on free, so PRIO_ANCHOR/RR_PRIO settings can survive in the shared scheduler pool and affect later allocations. Add otx2_qos_reset_schq_topology() and otx2_qos_free_hw_schq() to zero TL4 through TL2 TOPOLOGY before each schq is returned to the AF during hierarchy teardown and cfg rollback. Skip the aggregation level (TL1): it is a per-tx-link queue shared by the PF, default Tx hierarchy and VFs, and is not freed back to the AF by nix_txschq_free_one().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97969", "url": "https://ubuntu.com/security/CVE-2026-97969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix clock leak and spurious timer in settimeout() msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which introduces two severe bugs: 1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally. Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update `wdev->timeout`.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97970", "url": "https://ubuntu.com/security/CVE-2026-97970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Avoid division by zero clk_get_rate() could return 0. Avoid a division by zero panic.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97973", "url": "https://ubuntu.com/security/CVE-2026-97973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: destroy the phylink instance on the probe error path macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97977", "url": "https://ubuntu.com/security/CVE-2026-97977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Fix UAF of btusb_data by rx_work btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns. btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data: \twhile ((skb = skb_dequeue(&data->acl_q))) \t\tdata->recv_acl(data->hdev, skb); Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97979", "url": "https://ubuntu.com/security/CVE-2026-97979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: add missing xa_destroy for sched_node_ids Commit 16dfa49406bc (\"ice: Introduce new parameters in ice_sched_node\") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97981", "url": "https://ubuntu.com/security/CVE-2026-97981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97982", "url": "https://ubuntu.com/security/CVE-2026-97982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Fix budget accounting The gmac_rx() function returns the remaining NAPI budget, but its caller treats the return value as the number of packets received. An idle poll therefore reports a full budget and remains scheduled. Return the number of received packets instead. Preserve the existing free queue refill accounting by adding that count directly; continuing to subtract it from the budget would invert the refill behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97984", "url": "https://ubuntu.com/security/CVE-2026-97984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce (included in the new selftest): 1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of IPv6 header). Device MTU allows it (it's only one byte bigger than IP6_MAX_MTU, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only. The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc (\"net: ipv6: introduce ip6_dst_mtu_maybe_forward\"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 (\"[INET]: Add IP(V6)_PMTUDISC_RPOBE\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97986", "url": "https://ubuntu.com/security/CVE-2026-97986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_input: stop callbacks before unregistering input device virtinput_remove() unregisters the input device before resetting the virtio device. virtinput_recv_events() drops vi->lock around input_event(), so clearing vi->ready does not stop a callback that passed the entry check. It can still use vi->idev, requeue buffers and kick the queue. Reset first, as virtinput_freeze() already does. With the preceding core change, reset waits for callbacks before input_unregister_device() can free vi->idev. Recheck vi->ready after taking the lock again: keep draining completed events so an input packet is not truncated, but stop requeueing buffers and kicking the queue. With evdev attached, input_unregister_handle() currently waits for an RCU grace period, which also waits out IRQ callbacks. This masks the lifetime bug on PCI and MMIO, but does not protect sleepable callbacks on other transports.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97987", "url": "https://ubuntu.com/security/CVE-2026-97987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_input: reset device if input_register_device() fails Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97990", "url": "https://ubuntu.com/security/CVE-2026-97990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_net: check TX pull result before RX copy vringh_iov_pull_iotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb(). A negative error can therefore become a large length in the RX path. Handle non-positive pull results before every length use. Count the TX error and complete the consumed TX descriptor with zero bytes. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97991", "url": "https://ubuntu.com/security/CVE-2026-97991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_blk: reject out-of-range sector starts vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97993", "url": "https://ubuntu.com/security/CVE-2026-97993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx vhost_vdpa_set_config_call() swaps the eventfd_ctx_fdget() return value into v->config_ctx before checking it, so on failure the field briefly holds an ERR_PTR: \tctx = fd == VHOST_FILE_UNBIND ? NULL : eventfd_ctx_fdget(fd); \tswap(ctx, v->config_ctx); \tif (!IS_ERR_OR_NULL(ctx)) \t\teventfd_ctx_put(ctx); \tif (IS_ERR(v->config_ctx)) { \t\tlong ret = PTR_ERR(v->config_ctx); \t\tv->config_ctx = NULL; \t\treturn ret; \t} Commit 0bde59c1723a (\"vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails\") added that clearing, and spelled out the invariant the rest of the file relies on: \"we consider 'v->config_ctx' valid if it is not NULL\". The window between the swap and the clearing still breaks it. vhost_vdpa_config_cb() only tests for NULL, so a config interrupt delivered inside the window hands the ERR_PTR to eventfd_signal(). Check the fd before installing it instead. That closes the window and matches how vhost_vring_ioctl() handles the same failure for the vq call fd. It also stops a rejected fd from tearing down a config interrupt that was working: until now the swap replaced the live context and put it, so after an EBADF the device silently stopped delivering config interrupts until userspace installed a new fd.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97994", "url": "https://ubuntu.com/security/CVE-2026-97994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97995", "url": "https://ubuntu.com/security/CVE-2026-97995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): \tfree_buf \tremove_vqs \tvirtcons_remove \tunbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-97998", "url": "https://ubuntu.com/security/CVE-2026-97998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: cope with concurrent instance destruction Instances are refcounted. However, only memory release happens on the 1 -> 0 transition; the unlink from hashes can occur with any refcount. Uncooperative userspace can force a situation where a queue is pending for destruction from netlink event while a different socket with same portid processes an UNBIND request. With right timing, this will unhash the instance again: Oops: general protection fault, [..] Call Trace: nfulnl_recv_config+0x31a/0xd50 nfnetlink_rcv_msg+0x7c2/0xeb0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98006", "url": "https://ubuntu.com/security/CVE-2026-98006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev The epq_in_urb object belonging to the caiaq device is coupled within the struct snd_usb_caiaqdev. After usb_submit_urb(epq_in_urb, GFP_KERNEL) executes successfully, epq_in_urb is successfully added to the urbp_list queue of the dummy HCD driver (userspace specifies dummy_hcd as the HCD layer driver for the caiaq USB device). When init_card() calls snd_usb_caiaq_send_command() which subsequently fails due to a timeout, and proceeds to call snd_card_free() to release the card, the embedded ep1_in_urb object is also freed. When the dummy HCD driver detects that the URB has been unlinked, it returns the URB (by usb_hcd_giveback_urb()), which triggers [1]. Decouple the ep1_in_urb object from the struct snd_usb_caiaqdev and switch to using a pointer instead. Separately allocate and manage the memory for ep1_in_urb to prevent the release of the snd_card memory object from interfering with it. midi_out_urb has the same issue as ep1_in_urb and is handled in the same way. [1] BUG: KASAN: slab-use-after-free in usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 Write of size 4 at addr ffff88803cee1050 by task ktimers/1/29 Call Trace: usb_free_urb+0x24/0x120 drivers/usb/core/urb.c:96 dummy_timer+0xaac/0x4d50 drivers/usb/gadget/udc/dummy_hcd.c:2019 __run_hrtimer kernel/time/hrtimer.c:2067 [inline] __hrtimer_run_queues+0x3eb/0xaf0 kernel/time/hrtimer.c:2124 hrtimer_run_softirq+0x1e1/0x2e0 kernel/time/hrtimer.c:2141 Allocated by task 36: snd_card_new+0x7b/0x110 sound/core/init.c:184 create_card sound/usb/caiaq/device.c:429 [inline] snd_probe+0x236/0x1af0 sound/usb/caiaq/device.c:544 Freed by task 36: snd_card_free_when_closed sound/core/init.c:630 [inline] snd_card_free+0x138/0x1d0 sound/core/init.c:662 snd_probe+0x162b/0x1af0 sound/usb/caiaq/device.c:553", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98007", "url": "https://ubuntu.com/security/CVE-2026-98007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject non-scalar bpf_loop iteration counts bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 (\"bpf: keep track of max number of bpf_loop callback iterations\"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the \"backtracking misuse\" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98008", "url": "https://ubuntu.com/security/CVE-2026-98008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix NULL pointer dereference on unbind with fixed-link When the device tree describes a fixed-link and has no \"mdio\" child node, macb_mii_init() returns early without allocating the MDIO bus, leaving bp->mii_bus as NULL. Two cleanup paths then dereference this NULL bus: 1. On driver unbind, macb_remove() unconditionally calls mdiobus_unregister(bp->mii_bus), which oopses: Unable to handle kernel NULL pointer dereference at virtual address 00000000000004a8 pc : mdiobus_unregister+0x14/0xa4 lr : macb_remove+0x38/0xa4 Call trace: mdiobus_unregister+0x14/0xa4 (P) macb_remove+0x38/0xa4 platform_remove+0x20/0x30 device_release_driver_internal+0x1c8/0x224 unbind_store+0xb4/0xbc 2. On the probe error path in macb_probe(), reached when macb_mii_init() has succeeded but a subsequent step fails, the err_out_unregister_mdio label runs the same unconditional cleanup. mdiobus_unregister() and mdiobus_free() do not guard against a NULL bus, so guard the calls in both macb_remove() and the probe error path.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98009", "url": "https://ubuntu.com/security/CVE-2026-98009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: ets: clamp quantum in parse and fallback paths ets_qdisc_change() falls back to psched_mtu() with no floor for bands without an explicit quantum. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so a zero psched_mtu on a headerless device makes the deficit-refill loop spin under the qdisc lock. Move the floor into ets_quantum_parse() so explicitly configured quanta are also clamped to [256, 1<<20], not just the fallback path. Conditions to recreate the bug: CONFIG_NET_SCH_ETS=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root ets bands 3 strict 2 quanta 1 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98010", "url": "https://ubuntu.com/security/CVE-2026-98010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: drr: clamp quantum in change class drr_change_class() rejects explicit quantum==0 but falls back to psched_mtu() with no floor. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock. Add clamp_t(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved. Conditions to recreate the bug: CONFIG_NET_SCH_DRR=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98011", "url": "https://ubuntu.com/security/CVE-2026-98011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum in change and init paths hhf_change() accepts any quantum from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) in hhf_change() matching fq_codel_change(). Clamp hhf_init() to [256, 1<<20] matching the siblings, and remove the old fallback that only set quantum=256 on overflow. Conditions to recreate the bug: CONFIG_NET_SCH_HHF=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root hhf tc qdisc change dev dummy0 root hhf quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98012", "url": "https://ubuntu.com/security/CVE-2026-98012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98013", "url": "https://ubuntu.com/security/CVE-2026-98013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98014", "url": "https://ubuntu.com/security/CVE-2026-98014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable In mlx5_esw_vport_disable(), move esw_apply_vport_rx_mode() ahead of esw_vport_change_handle_locked() so vport->allmulti_rule is NULL before the change handler observes it. During FW-fatal recovery the disable runs while dev->state == INTERNAL_ERROR. The promisc query inside esw_update_vport_rx_mode() fails and returns early, leaving vport->allmulti_rule intact, so esw_update_vport_mc_promisc() runs and adds MLX5_ACTION_ADD entries to vport->mc_list whose flow rules are then installed in the FDB by esw_add_mc_addr(). esw_destroy_legacy_table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow_rule pointers in vport->mc_list. Two-stage failure on `echo 1 > /sys/bus/pci/devices//reset`: refcount_t: underflow; use-after-free. tree_put_node+0xef/0x110 [mlx5_core] clean_tree+0x44/0xd0 [mlx5_core] (x5) mlx5_fs_core_cleanup+0x57/0x1c0 [mlx5_core] mlx5_unload+0x65/0xd0 [mlx5_core] ... mlx5_health_try_recover BUG: unable to handle page fault for address: 0000000003000055 down_write+0x1c/0x60 mlx5_del_flow_rules+0x33/0x1f0 [mlx5_core] esw_del_mc_addr+0x7b/0x170 [mlx5_core] esw_apply_vport_addr_list+0x56/0xf0 [mlx5_core] esw_vport_change_handle_locked+0x28b/0x310 [mlx5_core] mlx5_esw_vport_enable+0x270/0x4a0 [mlx5_core] ... mlx5_load ... mlx5_health_try_recover esw_apply_vport_rx_mode(false, false) clears vport->allmulti_rule via its local state machine even when the FW del fails. With the rule NULL the !IS_ERR_OR_NULL(allmulti_rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc_list.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98015", "url": "https://ubuntu.com/security/CVE-2026-98015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98016", "url": "https://ubuntu.com/security/CVE-2026-98016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free race in sample_restore_put() Concurrent teardown of TC sample rules sharing the same restore context may re-read restore->count after dropping restore_lock. At that point another thread may already have completed cleanup and freed the restore object. Use the result of the refcount decrement while holding restore_lock to determine whether cleanup is needed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98017", "url": "https://ubuntu.com/security/CVE-2026-98017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: defer qdisc freeing after failed creation An RTM_NEWQDISC request can make clsact bind a populated shared ingress block during ->init(), publishing an embedded mini_Qdisc to lockless readers. If the same request has an invalid TCA_RATE, estimator setup fails after ->init(); the unwind removes the pointer but synchronously frees its containing qdisc while tc_run() may still hold it. Retire failed qdiscs through the same RCU helper as normal destruction. Inline the synchronous free into the callback now that no direct callers remain.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98020", "url": "https://ubuntu.com/security/CVE-2026-98020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix cmd_regs access racing BAR unmap on reset pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path clear/iounmap cmd_regs without devcmd_lock, and pdsc_legacy_firmware_update()'s download loop derefs cmd_regs after dropping and retaking the lock without re-checking. An FLR concurrent with a devlink flash can unmap cmd_regs under an in-flight devcmd, causing a NULL deref or a write to unmapped MMIO. Take devcmd_lock across the BAR unmap/remap, and re-check cmd_regs in the download loop. Only the PF maps cmd_regs and runs devcmd, so skip the unmap on a VF, as pdsc_remove() and pdsc_reset_done() already do. A reset that completes entirely within the unlocked window is not a correctness problem for the image: the device clears its update session, so a resumed download is rejected, and it verifies the staged image before writing a flash slot, reporting PDS_RC_BAD_FW rather than activating it. pdsc_unmap_bars() also clears info_regs, intr_status and intr_ctrl. The interrupt and start/stop readers of those are quiesced before the unmap by pdsc_fw_down(), which frees the interrupts and tears down the queues. The debugfs readers are not, since those files outlive a reset; that is pre-existing and out of scope here.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98022", "url": "https://ubuntu.com/security/CVE-2026-98022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations Several subsystems allocate ring buffers sized by dev->tx_queue_len with no upper bound. An unprivileged user (via unshare -Urn) can set a huge tx_queue_len and exhaust global memory with ring allocations: - pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len() allocate 3 skb_array rings of tx_queue_len entries each. - tun: tun_queue_resize() and the queue-attach path resize ptr_rings to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier. - tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init ptr_rings to tx_queue_len on the same notifier. netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN, sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767) there so the oversized value is rejected at set time. This takes effect whether the device is up or down, before dev->tx_queue_len is written, before any notifier fires, and before any ring is allocated. The \"> S16_MAX\" check also subsumes the previous unsigned-long truncation test, and a negative ifr_qlen from the ioctl lands far above the cap after conversion, so both old failure modes are covered by the one comparison. tx_queue_len is ambigious: both a per-ring sizing multiplier and a default queue-length/limit knob for consumers that allocate nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN policy in patch 2/3 while staying a legitimate queue length on high-BDP paths; the ring-memory trade-off of a shared knob is disclosed below. Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn). - pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach mq+pfifo_fast. ~28 iterations OOMs a 2GB guest. - tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to 500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a 512MB guest. - tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest. - On the fixed kernel the oversized tx_queue_len is rejected with -ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK create, sysfs, ioctl - the latter two via this check, the former two via this check and the 2/3 parse policy respectively).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98023", "url": "https://ubuntu.com/security/CVE-2026-98023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: reject dynamic fdb entries that reference a nexthop id The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled. Despite that, the VXLAN driver does not currently prevent such entries from being configured with the \"dynamic\" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption: list_del corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65 __list_del_entry_valid_or_report+0x1aa/0x210 ... vxlan_fdb_destroy+0x5b8/0xad0 vxlan_cleanup+0x328/0x450 call_timer_fn+0x2a/0x1c0 run_timer_softirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98024", "url": "https://ubuntu.com/security/CVE-2026-98024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ism: folio_put() after error dmb->cpu_addr was allocated via folio_alloc(). Use folio_put() instead of kfree() in the error exit of ism_alloc_dmb() to avoid slab allocator corruption. While at it, reset dmb->cpu_addr after folio_put to avoid unintentional UAF by future callers.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98025", "url": "https://ubuntu.com/security/CVE-2026-98025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is \t} else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB \"frame\" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98026", "url": "https://ubuntu.com/security/CVE-2026-98026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: properly convert mglist to rcu Sashiko reported a bug [1] that br_multicast_del_port_group unlists the port group not using proper rcu helper that preserves the next pointer and after that immediately frees the port group without waiting for rcu grace period. The only rcu walker of mglist is br_multicast_list_adjacent() and it turns out that function has always been buggy because mglist was never properly converted to RCU. Fix it by converting it to rcu and moving its initialization after eth_addr's. Initializing p->next can use RCU_INIT_POINTER because we have a barrier from the hlist_add_head_rcu call later, besides we're initializing an unpublished structure anyway. [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826014200.362304-1-littleddfu%40gmail.com", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98027", "url": "https://ubuntu.com/security/CVE-2026-98027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98030", "url": "https://ubuntu.com/security/CVE-2026-98030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into rule_locs[] without consulting nfc->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed CFP rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98031", "url": "https://ubuntu.com/security/CVE-2026-98031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Initialize extack in remove_nh_grp_entry() remove_nh_grp_entry() prints the extack message when a listener fails to replace the reduced nexthop group. However, extack is not initialized and listeners are not required to set a message when returning an error. Neither netdevsim nor mlxsw do so when an allocation fails, resulting in the dereference of an uninitialized stack pointer. Fix by zero-initializing extack, as was done in commit 6347c5314cee (\"nexthop: initialize extack in nh_res_bucket_migrate()\").", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98046", "url": "https://ubuntu.com/security/CVE-2026-98046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf_btf_find_by_name_kind() as sleepable When bpf_btf_find_by_name_kind() finds a type in module BTF, it returns a new BTF object fd through __btf_new_fd(). This reaches anon_inode_getfd(), which can sleep while allocating or expanding the current task fd table. The helper prototype does not set might_sleep, so the verifier allows the helper in non-sleepable contexts such as BPF timer callbacks. The fd allocation can then sleep in softirq context and install the fd into the interrupted task. Mark the helper as sleepable. This preserves calls from the main body of a sleepable syscall program while rejecting calls from its non-sleepable regions.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98051", "url": "https://ubuntu.com/security/CVE-2026-98051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times The loop initialised next_index from intf->tx_spb_index on every iteration, so incr_ring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances next_index and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98052", "url": "https://ubuntu.com/security/CVE-2026-98052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmasp: clear txcb->last before writing each descriptor bcmasp_xmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when tx_spb_ring_full() underreported fullness), bcmasp_tx_reclaim() would see last == true mid-SKB and call dev_consume_skb_any() prematurely, freeing the sk_buff while its remaining fragments were still in flight. Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98055", "url": "https://ubuntu.com/security/CVE-2026-98055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Clean up the bus when fetching ML caps fails snd_hdac_ext_bus_get_ml_capabilities() may fail and its return code shall be checked and accounted for. Address the issue by updating the error-path for avs_pci_probe(). At the same time, if the function in question succeeds but the next part of avs_pci_probe() fails, the hlink list shall be cleaned up before leaving the scope.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98063", "url": "https://ubuntu.com/security/CVE-2026-98063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref in btf_var_show() btf_var_show() calls btf_type_id_resolve() unconditionally, which dereferences btf->resolved_ids. That is NULL for a base BTF - e.g. the vmlinux BTF that bpf_snprintf_btf() renders against - since base BTF is not resolved during parsing. btf_modifier_show() guards this with 'if (btf->resolved_ids)', but btf_var_show() does not. A BPF program that passes the type_id of a BTF_KIND_VAR from the vmlinux BTF to bpf_snprintf_btf() thus NULL-derefs: KASAN: probably user-memory-access in range [0x46638-0x4663f] RIP: 0010:btf_var_show (kernel/bpf/btf.c:2929) Call Trace: btf_type_show (kernel/bpf/btf.c:8259) btf_type_snprintf_show (kernel/bpf/btf.c:8329) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Resolve the var's type directly with btf_type_skip_modifiers() when resolved_ids is NULL, mirroring btf_modifier_show().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98064", "url": "https://ubuntu.com/security/CVE-2026-98064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL-ptr-deref when showing a void BTF type btf_modifier_show() resolves the modifier and then calls btf_type_ops(t)->show() unconditionally. For the void type (type_id 0, BTF_KIND_UNKN) kind_ops[] has no entry, so ->show is NULL. A \"const void\" (a modifier resolving to void) cannot be a map key or value - map_check_btf() rejects it because void has no size - so the map dump path does not reach it. But bpf_snprintf_btf() takes a type_id straight from the BPF program, and passing such a \"const void\" from the vmlinux BTF NULL-derefs: KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] RIP: 0010:btf_modifier_show (kernel/bpf/btf.c:2914) Call Trace: btf_type_show (kernel/bpf/btf.c:8251) btf_type_snprintf_show (kernel/bpf/btf.c:8321) bpf_snprintf_btf (kernel/trace/bpf_trace.c:1047) bpf_prog_test_run_raw_tp (net/bpf/test_run.c:829) __sys_bpf (kernel/bpf/syscall.c:4804) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fall back to btf_df_show() when the resolved type has no show op; it emits the \"\" placeholder already used for kinds like FWD and FUNC. bpf_snprintf_btf() then returns the length as usual.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98066", "url": "https://ubuntu.com/security/CVE-2026-98066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Fix potential double-free at error path The fix for caiaq driver's resource management to handle the errors tries to release the resources in a common destructor call, but as a sashiko review for another patch suggested, some of the audio resources such as URBs have been already freed, and this may lead to a double-free. For addressing the double-free, call the common destructor function from each place, and assure that the resource pointers get cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98068", "url": "https://ubuntu.com/security/CVE-2026-98068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98069", "url": "https://ubuntu.com/security/CVE-2026-98069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire the fastpath locks in rds_conn_shutdown() rds_conn_shutdown() quiesces the transmit and receive-refill paths by waiting for RDS_IN_XMIT and RDS_RECV_REFILL to be sampled clear, and then runs the transport shutdown and rds_conn_path_reset(). Sampling the bits clear is not the same as owning them: the moment after the wait_event() returns, rds_send_xmit() can re-acquire RDS_IN_XMIT (or rds_ib_recv_refill() can re-acquire RDS_RECV_REFILL) and run concurrently with the teardown. The sender does recheck the connection state after taking the lock, but that recheck is a classic store-buffering pattern: teardown writes the state and reads the bit while the sender writes the bit and reads the state. acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write, and the transmit path then runs while the transport zeroes its rings (e.g. rds_ib_ring_init()) and rds_send_path_reset() rewrites the transmit state under it. Oracle UEK fixed the same class of crashes - a 14-year tail of BUG_ON()s in rds_ib_sub_signaled(), unexpected op-codes and NULL dereferences in rds_ib_send_cqe_handler() during failover testing - by making the teardown path *acquire* the fastpath bit locks instead of testing them (\"rds: Make sure transmit path and connection tear-down does not run concurrently\"). Ownership of a single word is decided by RMW atomicity, so no cross-variable ordering is needed. Do the same here: take both locks before calling the transport shutdown, hold them across rds_conn_path_reset(), and release them explicitly with a wake-up afterwards. Both are released with clear_bit_unlock(), so that the ring re-initialization done by the transport shutdown and the transmit state rewritten by rds_send_path_reset() are ordered before either bit is seen clear by the next acquire_in_xmit() or acquire_refill(). The fastpath users of these bits - rds_send_xmit() and rds_ib_recv_refill() - are trylock style and back off while teardown owns the locks, so no new lock dependency is introduced for them. rds_tcp_reset_callbacks() is different: since the previous patch it acquires RDS_IN_XMIT as well, and it blocks doing so, so its wait now spans the teardown instead of at most one send batch. That waiter runs from rds_tcp_accept_one() on the single-threaded krdsd workqueue and holds rds_tcp_accept_lock and t_conn_path_lock while it waits, so a duelling SYN accepted while its path is being torn down parks accept processing for the duration of the teardown - for TCP bounded by the (up to 5 s) drain loop in rds_tcp_conn_path_shutdown(). An IB path's drain in rds_ib_conn_path_shutdown() has no round cap, but no blocking waiter either: rds_tcp_reset_callbacks() is the only blocking acquirer of these bits and waits only on its own TCP path, and the fastpaths are trylock-and-back-off on both transports, so a long IB drain lengthens only that path's own quiesce. The window is narrow: the accept-side state check has to pass before the teardown moves the path to RDS_CONN_DISCONNECTING. Because krdsd is a single global workqueue, everything else queued there - accept processing for other connections and network namespaces, and the flush_workqueue(rds_wq) in rds_tcp_listen_stop() during namespace teardown - waits behind the parked accept worker for that time. It cannot deadlock, although the waits do point at each other: the teardown blocks until the bit's holder releases it, and the holder may be that krdsd accept worker. The holder finishes without needing anything the teardown owns: the sync cancels rds_tcp_reset_callbacks() issues target cp_send_w and cp_recv_w on the path's ordered cp_wq, whose only execution slot is occupied by the blocked cp_down_w itself, so they are pending at most and cancel without flushing - a reliance on cp_wq being ordered that is now noted next to those cancels (on ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98070", "url": "https://ubuntu.com/security/CVE-2026-98070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98071", "url": "https://ubuntu.com/security/CVE-2026-98071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: clear cp_flags bits individually in rds_conn_path_reset() rds_conn_path_reset() wipes the whole flag word with a plain cp->cp_flags = 0 store. Every other accessor of that word uses atomic bitops, and some of them can run concurrently with the reset: RDS_LL_SEND_FULL is set from rds_send_xmit() and cleared from the transport completion paths, neither of which holds anything that excludes the shutdown worker. A plain store racing an atomic read-modify-write on the same word is a data race, and whichever side loses has its update silently discarded. Clear the two bits the reset is actually responsible for instead. RDS_IN_XMIT and RDS_RECV_REFILL need no store at all here: they belong to the caller, rds_conn_shutdown(), which waits for both to be clear before calling the transport shutdown and this reset. This also gives every bit in cp_flags a single well-defined writer discipline, which the following patches rely on when they turn RDS_IN_XMIT and RDS_RECV_REFILL into bit locks held across the teardown: a blanket store mid-teardown would destroy lock ownership that an atomic clear preserves. Oracle UEK carries the same conversion (\"net/rds: Preserve essential connection state flags\"), motivated by its asynchronous shutdown state machine, whose progress and destroy flags must survive the reset. UEK's variant also clears RDS_IN_XMIT and RDS_RECV_REFILL because there the reset runs as the final step of a teardown that owns both bits, making those clears its unlock. Upstream that release belongs in rds_conn_shutdown(): once a later patch in this series turns the two bits into locks held across the teardown, ending ownership needs release semantics and a wake-up that a plain clear inside the reset would not provide. Based on Oracle UEK commit \"net/rds: Preserve essential connection state flags\" by Gerd Rausch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98072", "url": "https://ubuntu.com/security/CVE-2026-98072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in release_in_xmit() release_in_xmit() clears RDS_IN_XMIT with clear_bit_unlock() and then checks waitqueue_active() to decide whether anyone needs waking. clear_bit_unlock() is only a release operation: it orders the critical section before the bit clear, but does not order the subsequent plain load of the wait queue head after it. The waiter side does the mirror image - it adds itself to the wait queue and then tests the bit. That is the classic store-buffering pattern: the releasing CPU can read the wait queue as empty while the waiting CPU still reads the bit as set, so the sleeper is never woken. The waiters are rds_conn_shutdown() and rds_tcp_reset_callbacks(), both in uninterruptible wait_event() with no timeout. A lost wake-up strands the shutdown worker on its single-threaded workqueue until some other sender releases the bit again - and on a connection that is being torn down precisely because it failed, there may never be another sender. The barrier used to be there: release_in_xmit() did clear_bit() followed by smp_mb__after_atomic() until commit 1422f28826d2 (\"rds: introduce acquire/release ordering in acquire/release_in_xmit()\") folded both into clear_bit_unlock(), which strengthened the lock hand-off but silently dropped the full barrier the wake-up check depends on. The refill counterpart, release_refill() in net/rds/ib_recv.c, still carries its smp_mb__after_atomic() for exactly this reason. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98074", "url": "https://ubuntu.com/security/CVE-2026-98074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: do not clear curr_active_slave prematurely when releasing all slaves When releasing all slaves during bond destruction (all == true), __bond_release_one() unconditionally clears bond->curr_active_slave to NULL in every iteration. If a backup slave is released before the active slave, bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(), which increments the active slave dev promiscuity counter and sets bond_info->primary_is_promisc = 1. Because bond->curr_active_slave was prematurely cleared to NULL when releasing the backup slave, the subsequent iteration releasing the active slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL) is skipped. Consequently, bond_alb_handle_active_change() is never called to decrement the promiscuity counter, permanently leaking promiscuous mode on the physical device after bond teardown. When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets bond->curr_active_slave to NULL. We only need to avoid selecting a new active slave when all == true. Replace the if (all) branch with if (!all && oldcurrent == slave).", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98075", "url": "https://ubuntu.com/security/CVE-2026-98075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject BPF_PSEUDO_FUNC reference to the main program fixups.c:jit_subprogs() rewrites BPF_PSEUDO_FUNC loads to contain real function addresses. This function is invoked from bpf_jit_subprogs() only when env->subprog_cnt > 1. Meaning that for any program like below: int main(void *ctx) { void *ptr = main; ... bpf_timer_set_callback(..., ptr); ... } The 'ptr' won't be ever converted to contain an address. In combination with e.g. bpf_timer_set_callback() this would lead to a function call at a bogus address. Instead of complicating the implementation, just assume that no useful program needs main to be a sync or async callback and reject BPF_PSEUDO_FUNC loads for the main subprogram.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98076", "url": "https://ubuntu.com/security/CVE-2026-98076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/probes: Fix use-after-free on field name/type of events with multiple probes The fields of a probe-based dynamic event (kprobe, uprobe, eprobe and fprobe events) are created in traceprobe_define_arg_fields() by handing the probe_arg name/type strings to trace_define_field(), which only stores the pointers without copying. Those strings are owned by the trace_probe and are freed when that probe is removed. An event can have several probes attached. The field list is defined only once, by the first probe that registers the event, but it is kept alive by any surviving sibling probe. Deleting just that first probe by symbol - # primary A: fields are defined from A's args echo 'p:kprobes/ev vfs_read a1=$arg1' > kprobe_events # append B: shares A's event call echo 'p:kprobes/ev vfs_write a1=$arg1' >> kprobe_events # delete only A (matched by symbol), B survives echo '-:kprobes/ev vfs_read' >> kprobe_events frees A's args (trace_probe_cleanup() -> traceprobe_free_probe_arg()), but trace_probe_unlink() keeps the trace_probe_event because the probe list is not empty. The event call stays registered via B while its fields now reference freed memory. Any field lookup then reads it, e.g. echo 'a1 == 1' > events/kprobes/ev/filter BUG: KASAN: slab-use-after-free in strcmp+0xa7/0xb0 Call Trace: strcmp trace_find_event_field parse_pred process_preds create_filter apply_event_filter event_filter_write field->name references parg->name (kstrdup'd, freed with the probe) and, for array arguments, field->type references parg->fmt (kmalloc'd, freed with the probe) - the scalar type otherwise points at the static fmttype rodata, which is safe. Have traceprobe_define_arg_fields() duplicate the name and type strings and anchor the copies on the trace_probe_event, which embeds the event call and outlives every individual probe; trace_probe_event_free() releases them. The reproducer above triggers reliably; the field lookup and the delete both run under event_mutex, so this is a dangling reference after removal rather than a race. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98077", "url": "https://ubuntu.com/security/CVE-2026-98077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace() sip_skip_whitespace() returns dptr unchanged when its own loop exhausts the buffer (dptr == limit), instead of NULL like its sibling sip_follow_continuation() returns on its own \"no more data\" path. ct_sip_get_header() only checks for NULL after calling it: dptr = sip_skip_whitespace(dptr, limit); if (dptr == NULL) break; if (*dptr != ':' || ++dptr >= limit) break; so a recognized header name followed only by spaces/tabs running to the exact end of the SIP payload, with no colon, makes the very next statement read one byte past the buffer. Make both \"no more data\" outcomes return NULL, matching the convention sip_follow_continuation() already uses and that both existing callers already check for.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98078", "url": "https://ubuntu.com/security/CVE-2026-98078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix reversed sequence option serialization hton_seq() expects the host-order source first and the unaligned network-order destination second. The version 1 sync sender passes these arguments in reverse for both sequence blocks. This leaves 24 bytes of the kmalloc-backed message unwritten. It may disclose stale heap data and replace the live connection sequence state with values read from the buffer. Pass the connection sequence state as the source and the message payload as the destination for both blocks.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98080", "url": "https://ubuntu.com/security/CVE-2026-98080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not force reloc root creation during qgroup_account_snapshot() [BUG] When running btrfs/252 with quota enabled through MKFS_OPTIONS=\"-O quota\", it has a high chance to trigger the following kernel warning and flips the fs RO: BTRFS info (device dm-2): relocating block group 30408704 flags metadata|dup ------------[ cut here ]------------ WARNING: fs/btrfs/extent-tree.c:879 at lookup_inline_extent_backref+0x74b/0x960 [btrfs], CPU#4: btrfs/2173 CPU: 4 UID: 0 PID: 2173 Comm: btrfs Not tainted 7.2.0-rc6-custom+ #457 PREEMPT(full) 3adc6528fb66f7a55fe1095385818e742f200aab Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:lookup_inline_extent_backref+0x74b/0x960 [btrfs] Call Trace: insert_inline_extent_backref+0x7c/0x160 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_inc_extent_ref+0xa9/0x270 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __btrfs_run_delayed_refs+0x4af/0x11c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_run_delayed_refs+0x9d/0xf0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshot+0x39d/0xf00 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] create_pending_snapshots+0x9b/0xc0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_commit_transaction+0x280/0xeb0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] prepare_to_relocate+0x147/0x200 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] relocate_block_group+0x6b/0x5e0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_block_group+0x92c/0x2380 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_relocate_chunk+0x3f/0x1a0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_balance+0xa2c/0x19c0 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] btrfs_ioctl+0x2839/0x2d30 [btrfs 32f09462c54d9c922fca74a3e4866f4aa7737b72] __x64_sys_ioctl+0x416/0x9a0 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- BTRFS info (device dm-2): leaf 4593991680 gen 233 total ptrs 175 free space 5953 owner 2 BTRFS info (device dm-2): refs 3 lock_owner 2173 current 2173 \titem 0 key (166772736 METADATA_ITEM 1) itemoff 16250 itemsize 33 \t\textent refs 1 gen 222 flags 2 \t\tref#0: tree block backref root 266 [ Skip the tree dump ] \titem 174 key (263225344 METADATA_ITEM 0) itemoff 10328 itemsize 33 \t\textent refs 1 gen 162 flags 258 \t\tref#0: tree block backref root 267 BTRFS error (device dm-2): extent item not found for insert, bytenr 179847168 num_bytes 16384 parent 4594335744 root_objectid 273 owner 0 offset 0 BTRFS error (device dm-2): failed to run delayed ref for logical 179847168 num_bytes 16384 type 182 action 1 ref_mod 1: -117 [CAUSE] The above error is showing that there is a tree reference to a metadata extent that is no longer there. With \"ref_verify\" mount option (requires CONFIG_BTRFS_DEBUG), there is some extra debug output: BTRFS error (device dm-2): dumping block entry [180961280 16384], num_refs 0, metadata 1, from disk 0 BTRFS error (device dm-2): root entry 256, num_refs 18446744073709551615 BTRFS error (device dm-2): root entry 273, num_refs 18446744073709551615 BTRFS error (device dm-2): Ref action 3, root 273, ref_root 273, parent 0, owner 0, offset 0, num_refs 1 btrfs_force_cow_block+0x129/0x7d0 [btrfs] btrfs_cow_block+0x10a/0x250 [btrfs] btrfs_search_slot+0x5eb/0xf40 [btrfs] btrfs_insert_empty_items+0x3a/0x70 [btrfs] insert_with_overflow+0x53/0x130 [btrfs] btrfs_insert_dir_item+0x125/0x290 [btrfs] btrfs_add_link+0xaa/0x410 [btrfs] btrfs_rename+0x5ea/0xcd0 [btrfs] btrfs_rename2+0x28/0x60 [btrfs] vfs_rename+0x5b2/0xe10 filename_renameat2+0x244/0x430 __x64_sys_rename+0x48/0x70 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98082", "url": "https://ubuntu.com/security/CVE-2026-98082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix the possible bioc_list memory leak during error There are two possible ways to leak bioc memory on btrfs_ordered_extent::bioc_list: - An error occurred for btrfs_insert_one_raid_extent() Then the function btrfs_insert_raid_extent() immediately return without freeing any bioc in the bioc_list. - An ordered extent hit an IO error In that case the ordered extent will have BTRFS_ORDERED_IOERR set, and skip the call on btrfs_insert_raid_extent() completely. Fix the problem by: - Introduce a new helper, btrfs_cleanup_ordered_bioc_list() Which will remove all bioc from the bioc_list, and release the bioc. - Call the above helper for btrfs_insert_raid_extent() So that the cleanup helper is always called no matter what. - Call the above helper for btrfs_finish_one_ordered() This is called just before the final release on the ordered extent. This was reported by Sashiko when reviewing another patch.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98083", "url": "https://ubuntu.com/security/CVE-2026-98083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix transaction use-after-free in raid stripe insertion If allocation of a RAID stripe extent fails, btrfs_insert_one_raid_extent() aborts and ends the transaction before returning -ENOMEM. btrfs_finish_one_ordered(), the production caller through btrfs_insert_raid_extent(), still owns the transaction handle. It handles the error by aborting the transaction and then reaches the common exit path, which ends the transaction again. The premature end can free the handle and drop its transaction reference. Transaction cleanup can then free the transaction before the caller's second abort accesses the handle and transaction, resulting in use-after-free. Keep the abort at the failure site, but let the caller's common exit path end the transaction once, after it has finished using both objects.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98086", "url": "https://ubuntu.com/security/CVE-2026-98086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: do not touch legacy_rmidi before it exists snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as \"legacy_rmidi is live\" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98088", "url": "https://ubuntu.com/security/CVE-2026-98088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98089", "url": "https://ubuntu.com/security/CVE-2026-98089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix uninitialized transport header access in alb_determine_nd() alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98090", "url": "https://ubuntu.com/security/CVE-2026-98090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: restore active device pointers after failed sprout btrfs_init_new_device() switches latest_dev and possibly s_bdev from the seed device to the new sprout device before creating the first writable chunks. If chunk creation or the subsequent sprout setup fails, the error path releases the new device without switching those pointers back. btrfs_show_devname() can then dereference the freed latest_dev and crash. Restore the active device pointers to the latest seed device before removing and releasing the failed sprout device.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98091", "url": "https://ubuntu.com/security/CVE-2026-98091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: detach failed sprout device from transaction update list When creating the first metadata chunk for a sprout filesystem, create_chunk() adds the new device to the transaction dev_update_list through device->post_commit_list. If the subsequent system chunk creation fails, btrfs_init_new_device() aborts the transaction and releases the device while post_commit_list is still linked. This triggers a warning in btrfs_free_device() and leaves the transaction list referencing freed memory. Detach the device while holding chunk_mutex before releasing it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98092", "url": "https://ubuntu.com/security/CVE-2026-98092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98094", "url": "https://ubuntu.com/security/CVE-2026-98094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: fbtft: make dirty_lock IRQ-safe fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98095", "url": "https://ubuntu.com/security/CVE-2026-98095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header(). syzbot reported BUG() in sock_sendmsg_nosec(). [0] The problem is that tpacket_parse_header() casts user-provided tpacket_hdr.tp_len, which is u32, to int. If the length is larger than INT_MAX, the following condition in tpacket_parse_header() passes, if (unlikely(tp_len > size_max)) and any negative value can be returned to the caller, up to sock_sendmsg_nosec(). The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec(). *(uint64_t*)0x200000000008 = 0xfffffdef; ... syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul); Let's define the local tp_len as u32 in tpacket_parse_header(). [0]: kernel BUG at net/socket.c:803! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803 Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28 RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293 RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80 RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8 R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001 R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310 FS: 000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0 Call Trace: __sock_sendmsg net/socket.c:815 [inline] sock_write_iter+0x2de/0x3e0 net/socket.c:1266 new_sync_write fs/read_write.c:595 [inline] vfs_write+0x612/0xba0 fs/read_write.c:687 ksys_write+0x150/0x270 fs/read_write.c:739 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline] do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f173130ecb9 Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 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 d8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9 RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388 R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002 ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98096", "url": "https://ubuntu.com/security/CVE-2026-98096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: restore network header before routing and forwarding ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH) while skb_network_header() points at the IPv6 header. When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately followed the fixed IPv6 header. If another extension header (such as a Hop-by-Hop options header) precedes the SRH, skb_network_offset() remained negative. This led to two problems: 1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes __skb_flow_dissect() which passes the negative skb_network_offset() to flow dissection, breaking BPF and C flow dissector logic. 2. If forwarded via ip6_forward() or redirected via act_mirred, downstream handlers (like sch_fragment() or neighbour output) pass the negative offset as an unsigned length, triggering OOB memcpy or buffer overflows. Fix this by pushing -skb_network_offset(skb) before routing, ensuring skb_network_offset(skb) is 0 for route lookup / flow dissection as well as downstream forwarding. On the loopback path, pull skb_transport_offset(skb) to restore skb->data to the SRH before looping back.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98098", "url": "https://ubuntu.com/security/CVE-2026-98098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in tipc_named_node_up() on empty publication list User-space applications can bind a large number of service addresses to one or more sockets. Each binding of a local-scope service address inserts one entry (publication) into the TIPC name table. If the number of these publications exceeds TIPC_MAX_PUBL (65535), protocol service types (such as node state and link state) are no longer inserted into the name table. This causes two issues: 1. User-space applications subscribing to node or link up/down events stop receiving notifications. 2. A NULL pointer dereference can occur: BUG: kernel NULL pointer dereference, address: 00000000000000d0 ... CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full) ... RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221) ... Call Trace: tipc_node_write_unlock (net/tipc/node.c:428) tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189) tipc_udp_recv (net/tipc/udp_media.c:389) Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute) -----------------------------|----------------------------- | ... | list_for_each_entry(publ, pls, binding_node) { | ... | __skb_queue_tail(list, skb); | ... | } | ... | hdr = buf_msg(skb_peek_tail(list)); ... | tipc_nametbl_publish(); | If 'tipc_nametbl_publish()' (Thread 1) fails because the number of local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference. Fix these issues by allowing protocol service types (node state, link state, and topology server) to be inserted into the name table unconditionally. This ensures that users subscribing to these types always receive notifications. In addition, the maximum number of local user publications is reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size calculated in tipc_link_set_queue_limits() remains valid.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98104", "url": "https://ubuntu.com/security/CVE-2026-98104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused — one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) — ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables.", "cve_priority": "high", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98108", "url": "https://ubuntu.com/security/CVE-2026-98108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect. It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident. Fix by setting chan->mode correctly in l2cap_le_connect_req(). Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98109", "url": "https://ubuntu.com/security/CVE-2026-98109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix race condition during device registration In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98111", "url": "https://ubuntu.com/security/CVE-2026-98111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: validate version TLV value lengths btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98113", "url": "https://ubuntu.com/security/CVE-2026-98113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: rate limit unmapped SID errors A client can include many structurally valid but unmapped SIDs in a DACL. Logging every mapping failure lets one request generate hundreds of kernel error messages. Rate limit the message to prevent an authenticated client from flooding the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98116", "url": "https://ubuntu.com/security/CVE-2026-98116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation with an mmap_count check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: snd_pcm_sync_stop(), constraint refinement and do_free_pages() all happen in between. snd_pcm_mmap_data(), on the other hand, takes no lock at all: it validates against the old buffer's state and dma_bytes, remaps its pages into the VMA, and only then increments mmap_count. A concurrent mmap() can therefore slip in between the check and the free. remap_pfn_range() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent do_free_pages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation. Make snd_pcm_mmap_data() participate in the buffer-access scheme introduced for hw_params/hw_free: acquire runtime->buffer_accessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave. A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98121", "url": "https://ubuntu.com/security/CVE-2026-98121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: msc313e: Fix NULL pointer dereference in PM callbacks msc313e_wdt_probe() doesn't set the driver data for the platform device. As a result, dev_get_drvdata() in msc313e_wdt_suspend() and msc313e_wdt_resume() will return NULL, leading to a NULL pointer dereference afterward. Set the platform device driver data in msc313e_wdt_probe().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98122", "url": "https://ubuntu.com/security/CVE-2026-98122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every MDBE_ATTR_SRC_LIST member, accepts the all-zeros address. A source list is only accepted on a (*, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (*, G) key and resolves to the same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is then left with a zero address family. vxlan_mdb_remote_src_del() removes the forwarding entry of a source before freeing the source entry: \tvxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr); \tvxlan_mdb_remote_src_entry_del(ent); With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlist_del() reads ->pprev and ->next out of it and writes through them. Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlan_mdb_remote_srcs_replace(). BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 __vxlan_mdb_add+0x1cd/0xd70 vxlan_mdb_add+0xc0/0x140 rtnl_mdb_add+0x157/0x2a0 rtnetlink_rcv_msg+0x207/0x5a0 Allocated by task 84: __kmalloc_cache_noprof+0x153/0x360 vxlan_mdb_remote_srcs_add+0x2eb/0x440 __vxlan_mdb_add+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlan_mdb_remote_del+0x129/0x1a0 __vxlan_mdb_del+0x4f/0xe0 vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0 __vxlan_mdb_add+0x1c5/0xd70 The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers both call sites. A (*, G) entry is expressed by omitting the source, so nothing legitimate is refused. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98123", "url": "https://ubuntu.com/security/CVE-2026-98123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98128", "url": "https://ubuntu.com/security/CVE-2026-98128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add() mpi3mr_get_tgtdev_by_addr() increments the target device kref when it returns a device. If a subsequent error triggers a goto out_fail after the tgtdev reference is acquired, the reference is never released because the out_fail path does not call mpi3mr_tgtdev_put(). This prevents the target device structure from ever being freed. Add a tgtdev put in the out_fail path, guarded by a NULL check since tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup path is shared by earlier error cases where tgtdev is still NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98129", "url": "https://ubuntu.com/security/CVE-2026-98129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add() sas_port_alloc_num() can return NULL on memory allocation failure. The return value is passed directly to sas_port_add() without a NULL check, which causes a NULL pointer dereference. Additionally, if sas_port_add() fails, the allocated port is not freed before jumping to out_fail, leaking the sas_port structure. Call sas_port_free() to properly release it.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98130", "url": "https://ubuntu.com/security/CVE-2026-98130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98142", "url": "https://ubuntu.com/security/CVE-2026-98142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/cirrus-qemu: Validate BAR0 size during probe The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`. If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created. When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault: BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace: iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline] drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442 cirrus_primary_plane_helper_atomic_update+0x98a/0xb00 drivers/gpu/drm/tiny/cirrus-qemu.c:358 drm_atomic_helper_commit_planes+0x626/0xea0 drivers/gpu/drm/drm_atomic_helper.c:3038 drm_atomic_helper_commit_tail+0x60/0x510 drivers/gpu/drm/drm_atomic_helper.c:1989 commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074 drm_atomic_helper_commit+0xa77/0xb10 drivers/gpu/drm/drm_atomic_helper.c:2312 Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.", "cve_priority": "low", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98154", "url": "https://ubuntu.com/security/CVE-2026-98154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix -EIO cleanup order in queue_rq On -EIO, the RDMA queue_rq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete. Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98155", "url": "https://ubuntu.com/security/CVE-2026-98155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Address potential out-of-bounds read in resp_worker() Although 'commit 2feec5ae5df7 (\"accel/qaic: Handle DBC deactivation if the owner went away\")' fixes the scenario it was intended for by walking the message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it skipped over the bounds checking code that is included in decode_message(). This could lead to issues such as reading past the slab allocation's end, infinite loops or kernel panics. For those issues to happen, a malformed wire message is needed to be sent from the device. Instead of duplicating the bounds checking code already present in decode_message(), use the function inside resp_worker().", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98157", "url": "https://ubuntu.com/security/CVE-2026-98157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation The poll_msec sysfs store file uses simple_strtoul() which accepts an unsigned long, but the target field (poll_msec) is unsigned int. On 64-bit systems, a value > UINT_MAX is silently truncated when stored. Fix the mismatch by using kstrtouint() instead. This rejects values larger than UINT_MAX at parse time, making truncation impossible. Also add a check for value < 1 to reject the 0-delay case, which would cause the poll work to spin without delay and consume 100% CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-89796", "url": "https://ubuntu.com/security/CVE-2026-89796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Patch series \"mm/damon: unurgent fixes for infinite loop, NULL de-ref and races\", v1.1. Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those. This patch (of 6): Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-80521", "url": "https://ubuntu.com/security/CVE-2026-80521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge().", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74521", "url": "https://ubuntu.com/security/CVE-2026-74521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use memcmp() to compare ClientGUIDs ClientGUID is a fixed-size binary value and can contain embedded NUL bytes. strncmp() stops comparing at the first NUL byte, so different ClientGUID values can incorrectly be treated as equal. Use memcmp() in SMB3 multichannel session binding and FSCTL_VALIDATE_NEGOTIATE_INFO to compare all SMB2_CLIENT_GUID_SIZE bytes.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74294", "url": "https://ubuntu.com/security/CVE-2026-74294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: aiu: Validate written enum values The AIU HDMI and internal codec mux put callbacks use the written enum value with snd_soc_enum_item_to_val() before checking whether the value is valid for the enumeration. Reject out-of-range values before converting the enum item, matching the validation already done by the G12A HDMI and internal codec mux controls.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74291", "url": "https://ubuntu.com/security/CVE-2026-74291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74289", "url": "https://ubuntu.com/security/CVE-2026-74289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't dump dying fib_info in fib_leaf_notify(). syzbot reported use-after-free in nsim_fib4_prepare_event(). [0] The problem is that the following functions call fib_info_hold() / refcount_inc() while dumping fib_info under RCU, which is unsafe. * mlxsw_sp_router_fib4_event() * rocker_router_fib_event() * nsim_fib4_prepare_event() refcount_inc_not_zero() must be used, but it would be too late there. Let's guarantee the lifetime of fib_info in fib_leaf_notify(). Note that IPv6 does not need the corresponding change since fib6_table_dump() holds fib6_table.tb6_lock. [0]: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: kworker/u8:15/3420 Modules linked in: CPU: 0 UID: 0 PID: 3420 Comm: kworker/u8:15 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 Workqueue: netns cleanup_net RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25 Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 1b f1 22 fd 48 8d 3d 84 cb f1 0a 67 48 0f b9 3a eb 4a e8 08 f1 22 fd 48 8d 3d 81 cb f1 0a <67> 48 0f b9 3a eb 37 e8 f5 f0 22 fd 48 8d 3d 7e cb f1 0a 67 48 0f RSP: 0018:ffffc9000f2c7270 EFLAGS: 00010293 RAX: ffffffff84a18858 RBX: 0000000000000002 RCX: ffff888032ff9ec0 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8f9353e0 RBP: 0000000000000000 R08: ffff888032ff9ec0 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880570cc000 R13: dffffc0000000000 R14: ffff88802b40563c R15: ffff8880570cc000 FS: 0000000000000000(0000) GS:ffff888126173000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1f4d5d000 CR3: 000000006072a000 CR4: 00000000003526f0 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] fib_info_hold include/net/ip_fib.h:629 [inline] nsim_fib4_prepare_event drivers/net/netdevsim/fib.c:930 [inline] nsim_fib_event_schedule_work drivers/net/netdevsim/fib.c:1000 [inline] nsim_fib_event_nb+0x1055/0x1240 drivers/net/netdevsim/fib.c:1043 call_fib_notifier+0x45/0x80 net/core/fib_notifier.c:25 call_fib_entry_notifier net/ipv4/fib_trie.c:90 [inline] fib_leaf_notify net/ipv4/fib_trie.c:2176 [inline] fib_table_notify net/ipv4/fib_trie.c:2194 [inline] fib_notify+0x36b/0x5e0 net/ipv4/fib_trie.c:2217 fib_net_dump net/core/fib_notifier.c:70 [inline] register_fib_notifier+0x184/0x360 net/core/fib_notifier.c:108 nsim_fib_create+0x85d/0x9f0 drivers/net/netdevsim/fib.c:1596 nsim_dev_reload_create drivers/net/netdevsim/dev.c:1604 [inline] nsim_dev_reload_up+0x374/0x7c0 drivers/net/netdevsim/dev.c:1058 devlink_reload+0x501/0x8d0 net/devlink/dev.c:475 devlink_pernet_pre_exit+0x1ff/0x420 net/devlink/core.c:558 ops_pre_exit_list net/core/net_namespace.c:161 [inline] ops_undo_list+0x187/0x940 net/core/net_namespace.c:234 cleanup_net+0x56e/0x800 net/core/net_namespace.c:702 process_one_work kernel/workqueue.c:3314 [inline] process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74258", "url": "https://ubuntu.com/security/CVE-2026-74258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Guard __get_user acesss with access_ok for uprobe_multi data As reported by sashiko [1] we need to use access_ok to check the user space data bounds before we use __get-user to get it. [1] https://lore.kernel.org/bpf/20260610145235.CB1441F00893@smtp.kernel.org/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72496", "url": "https://ubuntu.com/security/CVE-2026-72496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72485", "url": "https://ubuntu.com/security/CVE-2026-72485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: platform: defer connection counter increment until alloc succeeds coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72413", "url": "https://ubuntu.com/security/CVE-2026-72413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix err_chunk memory leaks in INIT handling When sctp_verify_init() encounters unrecognized parameters, it allocates an err_chunk to report them. However, this chunk is leaked in several code paths: 1. In sctp_sf_do_5_1B_init(), if security_sctp_assoc_request() fails after sctp_verify_init() has populated err_chunk, the function returns immediately without freeing it. 2. In sctp_sf_do_unexpected_init(), the same leak occurs on the security_sctp_assoc_request() failure path. 3. In sctp_sf_do_unexpected_init(), on the success path after copying unrecognized parameters to the INIT-ACK, the function returns without freeing err_chunk, unlike sctp_sf_do_5_1B_init() which properly frees it. Fix all three leaks by adding sctp_chunk_free(err_chunk) calls before returning in the error paths and on the success path in sctp_sf_do_unexpected_init().", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72402", "url": "https://ubuntu.com/security/CVE-2026-72402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Mask pseudo pointer values in verifier logs print_bpf_insn() masks ldimm64 immediates for pointer-bearing pseudo sources when pointer leaks are not allowed, but the mask only covers BPF_PSEUDO_MAP_FD and BPF_PSEUDO_MAP_VALUE. BPF_PSEUDO_MAP_IDX, BPF_PSEUDO_MAP_IDX_VALUE, and BPF_PSEUDO_BTF_ID can also be resolved to kernel pointer values before the verifier log prints the instruction. Include them in the existing pointer classification so the log prints 0x0 instead of the rewritten address.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72334", "url": "https://ubuntu.com/security/CVE-2026-72334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix malformed ISO_END/CONT handling Core specification (Part C vol 4 sec 5.4.5) does not exclude empty ISO_CONT, ISO_END packets. We currently reject them if they are last. If controller sends malformed sequence ISO_START -> rx_len = 4, ISO_CONT skb->len 4, ISO_START that ends payload in ISO_CONT, we leak conn->rx_skb. If controller sends too long ISO_END, we panic on skb_put. If controller sends too short ISO_END we accept it. Fix by marking unfinished ISO_START via conn->rx_skb != NULL. Check skb->len properly before skb_put. Combine the ISO_CONT/END code paths as they require the same initial checks. Reject too short ISO_END packets.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-68289", "url": "https://ubuntu.com/security/CVE-2026-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68288", "url": "https://ubuntu.com/security/CVE-2026-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68287", "url": "https://ubuntu.com/security/CVE-2026-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68286", "url": "https://ubuntu.com/security/CVE-2026-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-98158", "url": "https://ubuntu.com/security/CVE-2026-98158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: \t*(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: \terr: \t\tif (skb) { \t\t\t/* make skb appear as freshly allocated */ \t\t\tskb_trim(skb, 0); \t\t\tskb_reserve(skb, - skb_headroom(skb)); \t\t} ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev: kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-98159", "url": "https://ubuntu.com/security/CVE-2026-98159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: validate CLC firmware records The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying.", "cve_priority": "medium", "cve_public_date": "2026-09-25 11:17:00 UTC" }, { "cve": "CVE-2026-93288", "url": "https://ubuntu.com/security/CVE-2026-93288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state sashiko reports: \"nfnl_log_net_exit() calls nf_log_unset(), which clears the logger pointer without an RCU grace period. Immediately after, ops_free_list() frees the per-net state while concurrent packets might still be executing nf_log_packet() under rcu_read_lock().\" Clear the pointer via .pre_exit to make sure rcu readers have completed before pernet storage is free'd. The change in nf_log_syslog.c is only done for consistency: it doesn't use pernet data.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93781", "url": "https://ubuntu.com/security/CVE-2026-93781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Do not block on tag allocation in scsi_eh_lock_door() scsi_eh_lock_door() is called from scsi_restart_operations() while the host is still in the SHOST_RECOVERY state, i.e. before the host is switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the queues. It allocates a request via scsi_alloc_request() with no flags, so blk_mq_get_tag() may block waiting for a free sched tag when all tags are already in use. Those tags can be held by commands that were just requeued by scsi_eh_flush_done_q() during error handling. Such commands cannot be dispatched until the host leaves SHOST_RECOVERY and scsi_run_host_queues() is called - which only happens *after* scsi_eh_lock_door() returns. This forms a circular dependency: - scsi_eh_lock_door(), running in the SCSI error handler thread, waits for a sched tag held by a requeued command; - the requeued command cannot complete and release its sched tag until the error handler thread leaves scsi_restart_operations() and restart the queues. For devices with a single driver tag (e.g. USB storage) it is a guaranteed deadlock and I/O that can never be submitted. This problem has also been reproduced in our environment. Locking the door is a best-effort operation, and scsi_eh_lock_door() already returns silently when the request allocation fails. Pass BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails instead of blocking when no tag is available. This breaks the circular dependency and allows the error handler to finish restarting the queues, after which the pending commands are dispatched normally.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93782", "url": "https://ubuntu.com/security/CVE-2026-93782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: flush backend after device ioctls vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93783", "url": "https://ubuntu.com/security/CVE-2026-93783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences hdr->addr and hdr->ctrl without validating skb->len first. A truncated frame with skb->len less than the minimum header size causes an out-of-bounds read of uninitialized memory. Additionally, a zero-length frame causes skb->len-- to underflow to UINT_MAX, making skb_tail_pointer() read far past the buffer. Commit 23882b828c3c (\"Bluetooth: RFCOMM: validate skb length in MCC handlers\") fixed the same class of missing-length-check bugs in the MCC sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed. KMSAN reports: BUG: KMSAN: uninit-value in rfcomm_run ... Uninit was created at: __alloc_skb+0x474/0xb60 vhci_write+0xe9/0x870 Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1 (the minimum frame must have a 3-byte header and a 1-byte FCS).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93784", "url": "https://ubuntu.com/security/CVE-2026-93784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie() The KASAN allocation trace shows that a malformed IE buffer is stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any validation. The crash trace shows that a subsequent SIOCSIWESSID triggers a connection attempt which calls cfg80211_sme_get_conn_ies() to process the stored IE buffer, causing: - An out-of-bounds read in skip_ie() which reads ies[pos+1] (the length byte) past the end of the 1-byte buffer. - An integer underflow in the memcpy size argument when offs returned by ieee80211_ie_split() exceeds ies_len, causing unsigned subtraction to wrap to SIZE_MAX and triggering a fortify panic. Fix this by validating the IE buffer in cfg80211_wext_siwgenie() before storing it. [drop unnecessary ie_len check, update commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93785", "url": "https://ubuntu.com/security/CVE-2026-93785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: validate idmap key payload length The cifs.idmap key type stores its payload length in key->datalen, which is limited to U16_MAX. Accepting a larger key payload truncates the recorded length and can make later users interpret the payload using inconsistent bounds. Reject oversized preparsed payloads before allocating or copying them. This keeps key->datalen consistent with the stored data for both inline and separately allocated idmap payloads.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93786", "url": "https://ubuntu.com/security/CVE-2026-93786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: preserve VFS inherited POSIX ACL mask The VFS initializes a child's POSIX ACL from the parent's default ACL and the requested creation mode. Do not mutate the parent ACL or overwrite the child's VFS-computed access and default ACLs afterwards. This preserves restrictive ACL_MASK entries and prevents SMB object creation from widening effective permissions.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93787", "url": "https://ubuntu.com/security/CVE-2026-93787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: bound dirent name against end of SMB response in cifs_filldir cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93788", "url": "https://ubuntu.com/security/CVE-2026-93788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: acpi: validate WGDS table revision index Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when firmware reports an invalid revision value.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93789", "url": "https://ubuntu.com/security/CVE-2026-93789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: bound aligned TLV advance in FW parser Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93790", "url": "https://ubuntu.com/security/CVE-2026-93790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93791", "url": "https://ubuntu.com/security/CVE-2026-93791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: add a check on the tid coming from the firmware ba_notif->tid is a firmware-controlled u8 that is used directly as an array index into tid_data[] without any validation. Add a bounds check against IWL_MAX_TID_COUNT before dereferencing the array.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93792", "url": "https://ubuntu.com/security/CVE-2026-93792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix a possible underflow We shouldn't trust the firmware about the length of the wowlan packet.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93794", "url": "https://ubuntu.com/security/CVE-2026-93794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: flush dirty data before punching a hole Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with: xfs_io -f \\ -c \"pwrite -b 3m -S 0x61 0 3m\" \\ -c \"fpunch 1m 1m\" \\ -c \"seek -h 0\" \\ -c \"seek -d 1m\" \\ /mnt/test/repro Punching 1 MiB at offset 1 MiB should produce: 0 1 MiB 2 MiB 3 MiB | DATA | HOLE | DATA | EOF Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M. This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole. Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA. The xfstests generic/539 pass against Samba/ksmbd with this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93795", "url": "https://ubuntu.com/security/CVE-2026-93795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix leaks and online flag on radix_tree_insert failure When radix_tree_insert() fails in blkg_create(), the error path has two issues: 1. blkg->online is set to true unconditionally, even when the blkg was never fully inserted. Move the assignment inside the success block. 2. The error path calls blkg_put() without first calling percpu_ref_kill(). Because the refcount is still in percpu mode, percpu_ref_put() only does this_cpu_sub() without checking for zero, so blkg_release() is never triggered. This permanently leaks the blkg memory, its percpu iostat, policy data, the parent blkg reference, and the cgroup css reference — the latter preventing the cgroup from ever being destroyed. Fix by replacing blkg_put() with percpu_ref_kill(), matching the pattern used in blkg_destroy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93797", "url": "https://ubuntu.com/security/CVE-2026-93797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix an off-by-1 boundary check Before looking at the 11th byte, check the length is big enough.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93798", "url": "https://ubuntu.com/security/CVE-2026-93798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reloc root cleanup in merge_reloc_roots() If the root we got has zero root refs in its root item, we are resetting the root's ->reloc_root without using barriers like we do everywhere else. Sashiko complained about this while reviewing another patch, and it's correct (see the Link tag below). Also, we should not clear BTRFS_ROOT_DEAD_RELOC_TREE from the root unless the root points to the reloc root we have. Fix this by using clear_reloc_root(), which issues the memory barrier after setting the root's ->reloc_root to NULL and before clearing the bit BTRFS_ROOT_DEAD_RELOC_TREE from the root.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93799", "url": "https://ubuntu.com/security/CVE-2026-93799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: validate sta_id in BA window status notif BA_WINDOW_STATUS_NOTIFICATION_ID extracts a 5-bit sta_id from the firmware notification and uses it to index fw_id_to_mac_id[] without bounds checking. Validate sta_id before array access to prevent out-of-bounds indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93800", "url": "https://ubuntu.com/security/CVE-2026-93800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free on reloc root after error in insert_dirty_subvol() If during relocation we fail in insert_dirty_subvol() because btrfs_update_reloc_root() returned an error, we will leave a root's reloc_root field pointing to a reloc root that was freed instead of NULL, resulting later in a use-after-free, or double free attempt during unmount. The sequence of steps is this: 1) During relocation the call to btrfs_update_reloc_root() in insert_dirty_subvol() fails, so insert_dirty_subvol() returns the error to merge_reloc_root() without adding the root to the list rc->dirty_subvol_roots; 2) Then merge_reloc_root() aborts the current transaction because insert_dirty_subvol() returned an error; 3) Up the call chain, merge_reloc_roots() gets the error, adds the reloc root for root X to the local reloc_roots list and jumps to the 'out' label, where it calls free_reloc_roots() to free all the reloc roots in the local reloc_roots list. This frees the reloc root for root X; 4) We go up the call chain to relocate_block_group() which calls clean_dirty_subvols() to go over dirty roots and set their ->reloc_root field to NULL, but root X is not in the dirty_subvol_roots list, so its ->reloc_root still points to a reloc root; 5) Relocation finishes, with an error and a transaction abort, but the ->reloc_root field for root X still points to the reloc root that was freed in step 3; 6) When unmounting the fs we end up calling: btrfs_free_fs_roots() btrfs_drop_and_free_fs_root() --> calls btrfs_put_root() against root X's ->reloc_root which is not NULL and points to the already freed reloc root in step 4 above Resulting in a use-after-free to a double free attempt. Syzbot reported this with the following dmesg/syslog: [ 106.004389][ T5339] BTRFS error (device loop0 state A): Transaction aborted (error -5) [ 106.014266][ T5339] BTRFS: error (device loop0 state A) in merge_reloc_root:1655: errno=-5 IO failure [ 106.021891][ T1061] BTRFS error (device loop0 state A): error while writing out transaction: -5 [ 106.026964][ T1061] BTRFS warning (device loop0 state A): Skipping commit of aborted transaction. [ 106.033807][ T5340] BTRFS error (device loop0 state A): bdev /dev/loop0 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0 [ 106.039265][ T1061] BTRFS: error (device loop0 state A) in cleanup_transaction:2067: errno=-5 IO failure [ 106.044382][ T5339] BTRFS info (device loop0 state EA): forced readonly [ 106.074329][ T5339] BTRFS: error (device loop0 state EA) in merge_reloc_roots:1887: errno=-5 IO failure [ 106.081004][ T5356] BTRFS info (device loop0 state EA): scrub: started on devid 1 [ 106.085611][ T5339] BTRFS info (device loop0 state EA): balance: ended with status: -30 [ 106.089517][ T5356] BTRFS info (device loop0 state EA): scrub: not finished on devid 1 with status: -30 [ 106.662365][ T5338] BTRFS info (device loop0 state EA): last unmount of filesystem 3a375e4e-b156-4d76-a2ad-16e198ce1409 [ 106.682946][ T5338] ================================================================== [ 106.686574][ T5338] BUG: KASAN: slab-use-after-free in btrfs_put_root+0x2f/0x250 [ 106.690090][ T5338] Write of size 4 at addr ffff88803f978630 by task syz.0.0/5338 [ 106.693173][ T5338] [ 106.694279][ T5338] CPU: 0 UID: 0 PID: 5338 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) [ 106.694293][ T5338] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 106.694300][ T5338] Call Trace: [ 106.694308][ T5338] [ 106.694314][ T5338] dump_stack_lvl+0xe8/0x150 [ 106.694331][ T5338] print_address_description+0x55/0x1e0 [ 106.694343][ T5338] ? btrfs_put_root+0x2f/0x250 [ 106.694358][ T5338] print_report+0x58/0x70 [ 106. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93802", "url": "https://ubuntu.com/security/CVE-2026-93802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: validate beacon length before fixed buffer copy rsi_prepare_beacon() copies the mac80211 beacon frame after FRAME_DESC_SZ into a management skb whose usable tailroom may be smaller than MAX_MGMT_PKT_SIZE after alignment. Validate the beacon length against the actual tailroom before the copy and skb_put(). Leave ownership of the management skb with the caller on error, matching the existing rsi_send_beacon() cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93803", "url": "https://ubuntu.com/security/CVE-2026-93803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libipw: fix key index receive bound checks libipw_rx() reads skb->data[hdrlen + 3] to extract the WEP key index in both the software-decrypt key selection path and the hardware-decrypted IV/ICV strip path. In both places the existing guard only checks skb->len >= hdrlen + 3, which proves bytes up to hdrlen + 2 but not the byte at hdrlen + 3. Require hdrlen + 4 bytes before reading that item in both paths. This is a local source-boundary check only; it does not change the key index semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93805", "url": "https://ubuntu.com/security/CVE-2026-93805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93806", "url": "https://ubuntu.com/security/CVE-2026-93806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate assoc response length before status and IE access cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run. Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93807", "url": "https://ubuntu.com/security/CVE-2026-93807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and data[24] whenever key data is present. Those offsets are only part of the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as CCMP, do not provide those bytes, so the unconditional copies can read past the supplied key buffer. Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are shorter than the expected 32-byte layout. [drop useless length check]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93808", "url": "https://ubuntu.com/security/CVE-2026-93808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: caiaq: validate EP1 reply lengths usb_ep1_command_reply_dispatch() uses buf[0] as a command byte and then reads command-specific fixed items from the same URB buffer. Several paths use buf + 1, buf[1], buf[2], or buf + 3 without first proving that urb->actual_length contains those bytes. Add per-command length checks, use a payload length derived from the bytes after the command byte for the control-state copy, and reject short analog input payloads before the input helper reads fixed offsets from the EP1 reply.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93809", "url": "https://ubuntu.com/security/CVE-2026-93809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: flush pending RCU callbacks on module unload Call rcu_barrier() in module exit to wait for outstanding call_rcu() callbacks before freeing module text, preventing late callback execution in freed memory. BUG: unable to handle page fault for address: ffffffffc1d59c40 PGD 6a12067 P4D 6a12067 PUD 6a14067 PMD 13698b067 PTE 0 Oops: 0010 [#1] SMP NOPTI RIP: 0010:0xffffffffc1d59c40 Code: Unable to access opcode bytes at RIP 0xffffffffc1d59c16. RSP: 0018:ffffc900198c0f28 EFLAGS: 00010286 RAX: ffffffffc1d59c40 RBX: ffff897c7d6b61c0 RCX: ffff88826aff4590 RDX: ffff8884d8b35490 RSI: ffffc900198c0f30 RDI: ffff88812af67290 RBP: 000000000000000a (DONE segment entries) R08: 0000000000000000 R09: 0000000000000100 R10: 0000000000000000 R11: ffffffff82a06100 R12: ffff88811a4e3700 R13: 0000000000000000 R14: ffff897c7d6b6270 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff897c7d680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc1d59c16 CR3: 00000104a980a001 CR4: 0000000002770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? rcu_do_batch+0x163/0x450 ? rcu_core+0x177/0x1c0 ? __do_softirq+0xc1/0x280 ? asm_call_irq_on_stack+0xf/0x20 ? do_softirq_own_stack+0x37/0x50 ? irq_exit_rcu+0xc4/0x100 ? sysvec_apic_timer_interrupt+0x36/0x80 ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? cpuidle_enter_state+0xd4/0x360 ? cpuidle_enter+0x29/0x40 ? cpuidle_idle_call+0x108/0x1a0 ? do_idle+0x77/0xf0 ? cpu_startup_entry+0x19/0x20 ? secondary_startup_64_no_verify+0xbf/0xcb (cherry picked from commit feaa5039f6c12acc9aa934c2d45dcd251a12c69f)", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93810", "url": "https://ubuntu.com/security/CVE-2026-93810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: Fix double fput Fix a double fput() in error handling in cachefiles_create_tmpfile().", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93811", "url": "https://ubuntu.com/security/CVE-2026-93811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling 1. When ndr_decode_v4_ntacl() fails, the code jumped to free_n_data which only freed n.data, skipping kfree(acl.sd_buf) and leaking the buffer. Zero-initialize struct xattr_ntacl acl, reorder error labels to out_free to release acl.sd_buf on all error paths. 2. if (acl.sd_size < sizeof(struct smb_ntsd)) is true, original code returned success without freeing sd_buf and left stale *pntsd. Set rc = -EINVAL before jumping to out_free to return error code and free buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93812", "url": "https://ubuntu.com/security/CVE-2026-93812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr ndr_encode_v4_ntacl() allocates sd_ndr.data via kzalloc() at entry. If any subsequent ndr_write_*() call returns error during encoding, the allocated sd_ndr.data won't be freed and causes memory leak. Move kfree(sd_ndr.data) into out label to ensure the buffer gets released on all success and error return paths.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93813", "url": "https://ubuntu.com/security/CVE-2026-93813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate INODE_REF's namelen [BUG] A crafted btrfs image can trigger the following crash: BUG: unable to handle page fault for address: ffffd1dc42884000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page CPU: 9 UID: 0 PID: 1034 Comm: poc Not tainted 7.1.0-rc4-custom+ #383 PREEMPT(full) 46af0a92938a63be7132e0dfd71e62327c51d5c2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:memcpy+0xc/0x10 Call Trace: read_extent_buffer+0xe4/0x100 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] btrfs_get_name+0x15e/0x1e0 [btrfs 3cf0785dd58fec8c5ff84633b772f17ce1f92a8f] reconnect_path+0x165/0x390 exportfs_decode_fh_raw+0x337/0x400 ? drop_caches_sysctl_handler+0xb0/0xb0 ---[ end trace 0000000000000000 ]--- RIP: 0010:memcpy+0xc/0x10 Kernel panic - not syncing: Fatal exception [CAUSE] TThe crafted image has the following corrupted INODE_REF item: item 9 key (258 INODE_REF 257) itemoff 11544 itemsize 4106 \tindex 2 namelen 4096 name: d\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000 The itemsize matches the namelen, but the namelen is 4096, way larger than normal name length limit (BTRFS_NAME_LEN, 255). Meanwhile the memory of the @name is only 255 byte sized, this will cause out-of-boundary access, and cause the above crash. [FIX] Add extra namelen verification for INODE_REF, just like what we have done in ROOT_REF checks. Now the crafted image can be rejected gracefully: BTRFS critical (device dm-2): corrupt leaf: root=5 block=30572544 slot=14 ino=259, invalid inode ref name length, has 4096 expect [1, 255] BTRFS error (device dm-2): read time tree block corruption detected on logical 30572544 mirror 2 [ Rebase, add a Link: tag, add an simple cause analyze ]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93814", "url": "https://ubuntu.com/security/CVE-2026-93814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: core: Abort active target transfer on controller suspend When an SPI controller operating in target mode has a transfer in progress at the time of system suspend, the suspend path proceeds without aborting the ongoing transfer. This can leave the hardware in an inconsistent state, potentially causing the system to hang or fail to resume cleanly. Fix this by invoking the controller's target_abort callback from spi_controller_suspend() when the controller is in target mode and the callback is registered. This ensures any active target transfer is cleanly terminated before the controller is suspended.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93815", "url": "https://ubuntu.com/security/CVE-2026-93815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: au1000: move free_irq out of the close-time spinlocked section au1000_close() calls free_irq() while aup->lock is still held with spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ descriptor request mutex, so it does not belong inside the close-time spinlocked section. This was found by our static analysis tool and then confirmed by manual review of the in-tree au1000_close() .ndo_stop path. The reviewed path keeps aup->lock held across the MAC reset, queue stop and free_irq(dev->irq, dev). A directed runtime validation kept that ndo_stop carrier and the same free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported \"BUG: sleeping function called from invalid context\" and \"Invalid wait context\" while free_irq() was taking desc->request_mutex, with au1000_close() and free_irq() on the stack. Drop aup->lock before freeing the IRQ. The protected close-time work still stops the device and queue before IRQ teardown, but the sleepable IRQ core path now runs outside the spinlocked section.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93816", "url": "https://ubuntu.com/security/CVE-2026-93816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate inline dentry name lengths before conversion Inline dentry conversion copies names out of the inline dentry area before checking that each recorded name length fits in the available filename slots. A corrupted image can therefore make the conversion path read past the inline filename storage while building the regular dentry block. Validate each inline dentry name length against the inline filename area before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93819", "url": "https://ubuntu.com/security/CVE-2026-93819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93820", "url": "https://ubuntu.com/security/CVE-2026-93820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: rockchip: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93821", "url": "https://ubuntu.com/security/CVE-2026-93821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93822", "url": "https://ubuntu.com/security/CVE-2026-93822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: iproc: Protect root bus removal with rescan lock Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. [bhelgaas: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93823", "url": "https://ubuntu.com/security/CVE-2026-93823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl amdkfd driver needs allocate buffer to return bo metadata to user space. The buffer size is controlled by user currently. It is a potential security issue that hostile value (e.g. 2 GiB) lets any render-group user trigger order-MAX allocation/OOM in kernel context. This patch first finds bo metadata size. If the size is smaller than user provided value drive can safely allocate buffer in kernel space and copy to user space buffer. If not, driver will let user know, not allocate and copy. User will redo with new buffer in user space. This patch lets driver decide buffer allocation size to avoid potential hostile size from user space. (cherry picked from commit f54ce9e8cbd3abe0eda3a285f54dc4f572fe589a)", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93824", "url": "https://ubuntu.com/security/CVE-2026-93824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: reject the combination of TLS and sockmap TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable. We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock). This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93825", "url": "https://ubuntu.com/security/CVE-2026-93825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data() Prevent NULL pointer dereference when spi_get_device_id() returns NULL, which can happen when using driver_override without matching SPI ID entry.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93826", "url": "https://ubuntu.com/security/CVE-2026-93826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hidpp: fix potential UAF in hidpp_connect_event() If input_register_device() fails, we call input_free_device(), but keep stale pointer to the old device in hidpp->input, which could potentially lead to UAF. Fix that by resetting it to NULL before returning from hidpp_connect_event().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93829", "url": "https://ubuntu.com/security/CVE-2026-93829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix races in cifsd thread creation The cifsd demultiplex thread can run and access tcp_ses before the parent thread has finished populating tcp_ses, which the worker thread accesses locklessly. Also, the kthread_run macro may start the thread before returning the thread pointer. Because the pointer is part of the structure that the thread can access, if the kernel is preempted after the thread is spawned, but before the thread pointer is populated and the thread attempts to exit, it will sleep, waiting for a SIGKILL signal. Fix this by moving creation of the thread to after all of tcp_ses'es fields are populated, and spawning the thread last, using a split kthread_create/wake_up_process logic.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-93830", "url": "https://ubuntu.com/security/CVE-2026-93830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97407", "url": "https://ubuntu.com/security/CVE-2026-97407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing hardware registers, but ignores its return value. If the runtime resume fails, the function continues to perform register accesses while the device state is undefined. Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and return early on failure to avoid unpowered register accesses.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97408", "url": "https://ubuntu.com/security/CVE-2026-97408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate connectionless PSM length Connectionless L2CAP frames carry a two-byte PSM at the start of the payload. l2cap_recv_frame() currently reads that PSM unconditionally after validating only the outer L2CAP length. A malformed connectionless frame with a zero- or one-byte payload can therefore make the parser read beyond the advertised skb payload and use tailroom bytes as part of the PSM. A VHCI-backed QEMU reproducer injected a one-byte connectionless payload and reached the unchecked read. Reject connectionless frames that cannot contain the PSM before reading or pulling it. This preserves all valid connectionless frames while dropping only structurally incomplete packets.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97409", "url": "https://ubuntu.com/security/CVE-2026-97409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Do not cancel requests in io target before it is initialized A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl(). nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace: dump_stack_lvl+0x57/0x80 register_lock_class+0x567/0x580 __lock_acquire+0x330/0xb90 lock_acquire.part.0+0xad/0x210 blk_mq_tagset_busy_iter+0xf9/0xc00 __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc] nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc] process_one_work+0x82c/0x1450 worker_thread+0x5ee/0xfd0 kthread+0x3a0/0x750 ret_from_fork+0x439/0x670 ret_from_fork_asm+0x1a/0x30 Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97411", "url": "https://ubuntu.com/security/CVE-2026-97411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: mal: fix potential system hang in mal_remove() napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97413", "url": "https://ubuntu.com/security/CVE-2026-97413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Fix integer underflow in process_read and process_write usr_len is read from a network-supplied message field (le16_to_cpu) and used to compute data_len = off - usr_len without validating that usr_len <= off. A malicious RDMA client can send usr_len > off causing an integer underflow, resulting in data_len wrapping to a huge size_t value which is then passed to the rdma_ev callback as a memory length, leading to out-of-bounds memory access. Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids() in both process_read() and process_write(), ensuring the early return path acquires no reference and has no resource leak.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97415", "url": "https://ubuntu.com/security/CVE-2026-97415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF ROOT_REF and ROOT_BACKREF items contain a struct btrfs_root_ref followed by the subvolume name. Several readers assume that this layout is already valid and then use the on-disk name length directly. A corrupted item can therefore make those readers address bytes outside the item, and BTRFS_IOC_GET_SUBVOL_INFO can copy too many bytes into its fixed-size UAPI name buffer. Validate ROOT_REF and ROOT_BACKREF items in tree-checker before any reader uses them. Reject records that do not contain a non-empty name, whose name_len does not exactly describe the remaining item payload, or whose name exceeds BTRFS_NAME_LEN. For BTRFS_IOC_GET_SUBVOL_INFO, copy only the validated on-disk name_len instead of deriving the copy length from the item size. The ioctl result is zeroed when allocated. That leaves the existing trailing zero byte untouched.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97416", "url": "https://ubuntu.com/security/CVE-2026-97416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk() [BUG] Running btrfs balance can trigger a null-ptr-deref before relocating a data chunk when metadata corruption leaves a chunk in the chunk tree without a corresponding block group in the in-memory cache: KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601 Call Trace: __btrfs_balance fs/btrfs/volumes.c:4217 [inline] btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604 btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline] btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313 ... [CAUSE] __btrfs_balance() iterates the on-disk chunk tree and passes the chunk logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data chunk. That helper then queries the in-memory block group cache: cache = btrfs_lookup_block_group(fs_info, chunk_offset); chunk_type = cache->flags; /* cache may be NULL */ A corrupt image can contain a chunk item whose matching block group item is missing, so no block group is ever inserted into the cache. In that case btrfs_lookup_block_group() returns NULL. The code only guards this with ASSERT(cache), which becomes a no-op when CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of cache->flags therefore crashes the kernel. [FIX] Add a NULL check after btrfs_lookup_block_group() in btrfs_may_alloc_data_chunk() and print and error message for clarity.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97417", "url": "https://ubuntu.com/security/CVE-2026-97417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack() The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97418", "url": "https://ubuntu.com/security/CVE-2026-97418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es18xx: check control allocation before private data setup snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97419", "url": "https://ubuntu.com/security/CVE-2026-97419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsr: broadcast netlink notifications in the device's net namespace The HSR generic netlink family sets .netnsok = true. HSR devices can live in network namespaces other than init_net. Two async notifiers broadcast events with genlmsg_multicast(). They are hsr_nl_ringerror() and hsr_nl_nodedown(). That helper delivers only on the default genl socket in init_net. So the events always land in init_net. The network namespace of the device does not matter. This has two effects. A listener in the device's own namespace never sees its own ring error and node down events. A privileged listener in init_net receives events from HSR devices in other namespaces. The payload carries the peer node MAC (HSR_A_NODE_ADDR) and the slave port ifindex (HSR_A_IFINDEX). Switch both callers to genlmsg_multicast_netns(). Other families with .netnsok = true already do this. Examples are gtp, ovpn, team, batman-adv, netdev-genl, ethtool and handshake. hsr_nl_ringerror() already has the slave port. It uses dev_net(port->dev). hsr_nl_nodedown() takes the namespace from the master port via hsr_port_get_hsr().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97420", "url": "https://ubuntu.com/security/CVE-2026-97420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97421", "url": "https://ubuntu.com/security/CVE-2026-97421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz() Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97425", "url": "https://ubuntu.com/security/CVE-2026-97425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix buffer overflow during vBIOS update Clamp the buffer postion to write by setting the bin attribute to the maximum buffer size so that VFS layer will block the out-of-bounds accessing.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97427", "url": "https://ubuntu.com/security/CVE-2026-97427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: bound pp_dpm_set_pp_table() memcpy The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97429", "url": "https://ubuntu.com/security/CVE-2026-97429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix UAF race in destroy_queue_cpsch wait_on_destroy_queue() drops locks to wait for queue resume, allowing a concurrent destroy to free the queue. Use is_being_destroyed flag to serialize destruction.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97430", "url": "https://ubuntu.com/security/CVE-2026-97430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: Prevent queuing new commands if xhci is inaccessible Refuse to queue a new command on the command ring if xHC is marked inaccessible with the HCD_FLAG_HW_ACCESSIBLE. HCD_FLAG_HW_ACCESSIBLE is set and cleared in suspend and resume. Also print a warning if xhci is being suspended with commands still pending on the command ring.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97434", "url": "https://ubuntu.com/security/CVE-2026-97434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix handling of NAPI on the remove path All the NAPI instances for a DPSW device are attached to the first switch port's net_device but shared by all ports. The NAPI instances get disabled only once the last port goes down. This causes an issue on the .remove() path where each port is unregistered and freed one at a time, causing the NAPI instances to be deleted even though they are not disabled. In order to avoid this, split up the unregister_netdev() calls from the free_netdev() so that we make sure all ports go down before we attempt a deletion of NAPI instances. Also, make the netif_napi_del() explicit as it is on the .probe() path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97435", "url": "https://ubuntu.com/security/CVE-2026-97435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97436", "url": "https://ubuntu.com/security/CVE-2026-97436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: rework FDB management on the bridge leave path On bridge leave, the dpaa2_switch_port_set_fdb() function always allocates a new FDB for the port which is becoming standalone. In case no FDB is found, then the port leaving a bridge will continue to use the current one. The above logic does not cover the case in which there are multiple bridges which have ports from the same DPSW instance. In this case, when the last port leaves bridge #1, it finds an unused FDB to switch to, but the old FDB is not marked as unused. Since the number of FDBs is equal to the number of DPSW interfaces, this will eventually lead to multiple ports sharing the same FDB. Fix this by changing how we are managing the FDBs on the leave path. Instead of directly allocating a new FDB, first verify if the current port is the last one to leave a bridge. If this is the case, then continue to use the current FDB and only allocate another FDB if there are other ports remaining in the bridge.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97437", "url": "https://ubuntu.com/security/CVE-2026-97437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e() The bounds check in ntfs_dir_emit() compares fname->name_len (a character count) against e->size (a byte count) without accounting for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME header size: if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size)) This computes: name_len + 16 > e_size The correct check must account for the ATTR_FILE_NAME header (66 bytes before the name) and the UTF-16LE character size (2 bytes each): sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) + name_len * sizeof(short) > e_size Which computes: 16 + 66 + name_len * 2 > e_size The correct calculation already exists as fname_full_size() in ntfs.h and is used in cmp_fnames(), namei.c, and fslog.c, but was not used in the readdir path. A crafted NTFS image with an index entry containing a small e->size but large fname->name_len bypasses the current check, causing ntfs_utf16_to_nls() to read past the entry boundary. Additionally, add a key_size validation in hdr_find_e() to ensure the declared key_size does not exceed the available entry data, preventing comparison functions from reading past entry boundaries on the lookup path.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97438", "url": "https://ubuntu.com/security/CVE-2026-97438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate index entry key bounds [BUG] A malformed NTFS directory index entry can advertise a key_size larger than the bytes actually present in its NTFS_DE payload. Directory lookup then passes that malformed key to cmp_fnames(), which can read past the end of the kmalloc'ed index buffer. BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline] BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 __asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378 fname_full_size fs/ntfs3/ntfs.h:590 [inline] cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46 hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762 indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... Allocated by task 9279: kasan_save_stack+0x39/0x70 mm/kasan/common.c:56 kasan_save_track+0x14/0x40 mm/kasan/common.c:77 kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __do_kmalloc_node mm/slub.c:5650 [inline] __kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662 kmalloc_noprof include/linux/slab.h:961 [inline] indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059 indx_find+0x447/0x900 fs/ntfs3/index.c:1179 dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254 ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85 __lookup_slow+0x241/0x450 fs/namei.c:1816 lookup_slow fs/namei.c:1833 [inline] walk_component+0x31c/0x570 fs/namei.c:2151 link_path_walk+0x592/0xd60 fs/namei.c:2519 path_lookupat+0x138/0x660 fs/namei.c:2675 filename_lookup+0x1f3/0x560 fs/namei.c:2705 filename_setxattr+0xad/0x1c0 fs/xattr.c:660 path_setxattrat+0x1d8/0x280 fs/xattr.c:713 __do_sys_lsetxattr fs/xattr.c:754 [inline] __se_sys_lsetxattr fs/xattr.c:750 [inline] __x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750 ... [CAUSE] The index-header validators only validated INDEX_HDR-level geometry. They did not walk each NTFS_DE to verify entry alignment, subnode layout, or that key_size fit inside the entry payload. They also allowed a last sentinel entry to carry a non-zero key_size. [FIX] Walk every NTFS_DE in ntfs3's index-header validators and reject entries with invalid layout, mismatched subnode state, oversized key_size, or non-zero sentinel keys before lookup or log replay can consume them.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97439", "url": "https://ubuntu.com/security/CVE-2026-97439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib [BUG] A corrupted ntfs3 image can hit a NULL function pointer call in generic_perform_write() after toggling system.ntfs_attrib and then overwriting system.dos_attrib on the same file. BUG: kernel NULL pointer dereference, address: 0000000000000000 \\#PF: supervisor instruction fetch in kernel mode \\#PF: error_code(0x0010) - not-present page PGD bed5067 P4D bed5067 PUD 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff88801025f988 EFLAGS: 00010246 Call Trace: generic_perform_write+0x409/0x8c0 mm/filemap.c:4255 __generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372 ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x63b/0xf70 fs/read_write.c:686 ksys_write+0x133/0x250 fs/read_write.c:738 __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x77/0xc0 fs/read_write.c:746 ... [CAUSE] system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags() and switches i_mapping->a_ops to ntfs_aops_cmpr when FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites ni->std_fa from a one-byte DOS attribute value, clearing the compression bit without updating ATTR_DATA or the mapping operations. Old buffered writes use is_compressed(ni) to choose __generic_file_write_iter(). That leaves generic_perform_write() calling a NULL write_begin callback from ntfs_aops_cmpr. [FIX] Treat system.dos_attrib as a low-byte DOS attribute update and preserve the existing non-DOS attribute bits in ni->std_fa. This keeps compressed and sparse state consistent with ATTR_DATA and the mapping operations while keeping the existing DOS attribute semantics intact.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97440", "url": "https://ubuntu.com/security/CVE-2026-97440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix node refcount leak on ctrl packet alloc failure qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a reference on the returned node. If the subsequent call to qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the function returns -ENOMEM without calling qrtr_node_release() to release the node reference. Add qrtr_node_release(node) before returning on the allocation failure path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97441", "url": "https://ubuntu.com/security/CVE-2026-97441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: ahci: fail probe if BAR too small for claimed ports When an AHCI controller is disabled in BIOS, its HOST_CAP register may contain a bogus value, e.g. 0xFFFFFFFF. Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field, a value of 0x1f means 32 ports. If CAP.NP claims more ports than can physically fit within the mapped BAR region, accessing port registers beyond the BAR boundary causes a kernel panic. Add validation in ahci_init_one() to check that the BAR size is sufficient for the number of ports claimed in CAP.NP. The check calculates the required MMIO size as: required_size = 0x100 (global registers) + max_ports * 0x80 If required_size exceeds the actual BAR size, the probe fails with -ENODEV, preventing the panic and providing a clear error message. [cassel: commit log]", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97442", "url": "https://ubuntu.com/security/CVE-2026-97442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97443", "url": "https://ubuntu.com/security/CVE-2026-97443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97444", "url": "https://ubuntu.com/security/CVE-2026-97444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in two places Add boundary checks in acpi_ps_get_next_namestring() and acpi_ps_peek_opcode() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97445", "url": "https://ubuntu.com/security/CVE-2026-97445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources() Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97446", "url": "https://ubuntu.com/security/CVE-2026-97446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package() acpi_ns_custom_package() unconditionally dereferences the first element of the package to read the _BIX version number, without checking for NULL: if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER) When firmware returns a _BIX package whose first element is an unresolvable reference, ACPICA evaluates that entry to NULL. acpi_ns_remove_null_elements() does not strip NULL entries for ACPI_PTYPE_CUSTOM packages (fixed-position format would break if elements were shifted), so acpi_ns_custom_package() sees the NULL and causes a crash. Add a NULL check for the first element (version field) before dereferencing it. The caller then receives AE_AML_OPERAND_TYPE instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97447", "url": "https://ubuntu.com/security/CVE-2026-97447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97448", "url": "https://ubuntu.com/security/CVE-2026-97448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add validation for node in acpi_ns_build_normalized_path() Add validation for node in acpi_ns_build_normalized_path() to prevent use-after-free vulnerabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97449", "url": "https://ubuntu.com/security/CVE-2026-97449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97450", "url": "https://ubuntu.com/security/CVE-2026-97450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate handler object type in two places ACPICA: validate handler object type in acpi_ev_has_default_handler() and acpi_ev_find_region_handler().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97451", "url": "https://ubuntu.com/security/CVE-2026-97451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op) Add overflow check for Index + Length to prevent integer overflow when calculating the truncation length. This prevents negative size parameter being passed to memcpy().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97452", "url": "https://ubuntu.com/security/CVE-2026-97452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Prevent adding invalid references Prevent adding references for local, argument, and debug objects in acpi_ut_copy_simple_object().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97453", "url": "https://ubuntu.com/security/CVE-2026-97453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: validate byte_count in acpi_ps_get_next_package_length() Validate package length reading in acpi_ps_get_next_package_length().", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97454", "url": "https://ubuntu.com/security/CVE-2026-97454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: add boundary checks in acpi_ps_get_next_field() Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97455", "url": "https://ubuntu.com/security/CVE-2026-97455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ds_terminate_control_method() Fix use-after-free issue in acpi_ds_terminate_control_method() by clearing references to method locals and arguments.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97456", "url": "https://ubuntu.com/security/CVE-2026-97456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97472", "url": "https://ubuntu.com/security/CVE-2026-97472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: fix temp address generation after prefix deprecation When a router temporarily deprecates an IPv6 prefix (either by sending a Router Advertisement with Preferred Lifetime = 0 or by letting the lifetime expire) and later restores it, the kernel permanently loses its ability to generate temporary privacy addresses (RFC 8981) for that prefix. This happens because the address worker attempts to generate a replacement temporary address when the current one nears expiration. As the base prefix is deprecated already, the generation fails after marking the temporary address as already having spawned a replacement (ifp->regen_count++). When the router eventually restores the prefix, the temporary address becomes active again. However, once it naturally expires, the address worker sees this temporary address already tried to generate one and skips the regeneration. Fix the issue by resetting the regen_count check of the latest temp address generated for the prefix updated by the incoming RA.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97475", "url": "https://ubuntu.com/security/CVE-2026-97475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tegra/soctherma: Switch to devm cooling device registration Use devm_thermal_of_cooling_device_register() to simplify resource management and avoid manual cleanup in error paths. As a side effect this change has the benefit of solving an existing issue. Before, the function tegra_soctherm_remove() only called debugfs_remove_recursive() and never called thermal_cooling_device_unregister() for any of the cooling devices registered here. After the driver removal, the thermal framework's cdev list would still hold references to thermal_cooling_device objects whose devdata pointer (ts) pointed to memory already freed by the platform device's devm cleanup. With this change, the cooling device is unregistered when the driver is removed, thus fixing the issue above.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97476", "url": "https://ubuntu.com/security/CVE-2026-97476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97481", "url": "https://ubuntu.com/security/CVE-2026-97481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix possible ISR soft lockup There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97482", "url": "https://ubuntu.com/security/CVE-2026-97482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET log goku_irq() handles a number of bus events under a single ep0 path. It already guards the gadget driver suspend/resume callbacks against a NULL ->driver: \tif (dev->gadget.speed != USB_SPEED_UNKNOWN \t\t\t&& dev->driver \t\t\t&& dev->driver->resume) { \t\tspin_unlock(&dev->lock); \t\tdev->driver->resume(&dev->gadget); \t\t... \t} but the very next branch unconditionally dereferences dev->driver when an INT_USBRESET arrives: \tif (stat & INT_USBRESET) { \t\tACK(INT_USBRESET); \t\tINFO(dev, \"USB reset done, gadget %s\\n\", \t\t\tdev->driver->driver.name); \t} If the controller raises INT_USBRESET before any gadget driver has been bound (or after one has been unbound), dev->driver is NULL and the printk dereferences NULL. smatch flags the inconsistency: drivers/usb/gadget/udc/goku_udc.c:1618 goku_irq() error: we previously assumed 'dev->driver' could be null (see line 1607) Fall back to a placeholder when the gadget driver is not bound. No functional change while a gadget driver is bound.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97483", "url": "https://ubuntu.com/security/CVE-2026-97483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: hcd: fix possible deadlock in rh control transfers >From within the SCSI error handler memory allocations must not trigger IO. Handling errors in UAS and the storage driver may involve resetting a device. The thread doing the reset itself relies on VM magic. However, that is insufficient, as resetting a device involves resuming it. Resumption as well as resetting involves conrol transfers to the parent of the device to be reset. That may be a root hub. Hence usbcore must heed the flags passed to usb_submit_urb() processing control transfers to root hubs. The problem exist since the storage driver has been merged.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97484", "url": "https://ubuntu.com/security/CVE-2026-97484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vhci_hcd: fix NULL deref in status_show_vhci platform_get_drvdata() can return NULL if a VHCI host controller's probe failed (e.g. due to USB bus number exhaustion). status_show_vhci() checked for a NULL pdev but not for a NULL hcd returned by platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not return NULL - it returns a pointer offset of 0x260, causing a NULL pointer dereference when that value is subsequently dereferenced. Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move status_show_not_ready() above status_show_vhci() to make it callable from the new error path without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97485", "url": "https://ubuntu.com/security/CVE-2026-97485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: omfs: handle set_blocksize failures omfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97486", "url": "https://ubuntu.com/security/CVE-2026-97486", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hpfs: handle set_blocksize failures hpfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97487", "url": "https://ubuntu.com/security/CVE-2026-97487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: handle set_blocksize failures jfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97488", "url": "https://ubuntu.com/security/CVE-2026-97488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qnx4: handle set_blocksize failures qnx4 uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97489", "url": "https://ubuntu.com/security/CVE-2026-97489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bfs: handle set_blocksize failures bfs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting will hit the \tBUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97490", "url": "https://ubuntu.com/security/CVE-2026-97490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: affs: handle set_blocksize failures affs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97491", "url": "https://ubuntu.com/security/CVE-2026-97491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: Don't sleep inside rds_ib_conn_path_shutdown New rds rdma self tests exposed a hang when tearing down the ib network configs. This is caused by the shutdown worker thread sleeping on the wait_event call, which blocks other work items in the queue. Fix this by changing wait_event to wait_event timeout, and looping until the wait check succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97495", "url": "https://ubuntu.com/security/CVE-2026-97495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on allocate_doorbell allocated_doorbell has an option to set the doorbell id to a specific value (used by CRIU). This value was not bounds checked. Check to confirm it's less than KFD_MAX_NUM_OF_QUEUES_PER_PROCESS.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97496", "url": "https://ubuntu.com/security/CVE-2026-97496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix OOB memory exposure in get_wave_state() The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3). this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers). Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user(). This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97497", "url": "https://ubuntu.com/security/CVE-2026-97497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id allocate_sdma_queue has an option where the sdma queue id can be specified (used by CRIU). We weren't bounds-checking that value. Confirm it's less than the maximum number of queues.", "cve_priority": "high", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97500", "url": "https://ubuntu.com/security/CVE-2026-97500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: phy: check length before parsing PHY status IE Hardware might report PHY status IE with unexpected length, and parser might access out of range. Check the length ahead.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97502", "url": "https://ubuntu.com/security/CVE-2026-97502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: avoid NULL deref of host->data in IRQ handler mmc_davinci_irq() returns early only when both host->cmd and host->data are NULL: if (host->cmd == NULL && host->data == NULL) { ... return IRQ_NONE; } So we may legitimately reach the rest of the handler with host->data == NULL (and therefore data == NULL). The DATDNE branch already guards against this with an explicit \"if (data != NULL)\" check, but the subsequent TOUTRD (\"read data timeout\") and CRCWR/CRCRD (\"data CRC error\") branches dereference data unconditionally: if (qstatus & MMCST0_TOUTRD) { data->error = -ETIMEDOUT; <-- NULL deref ... davinci_abort_data(host, data); } if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) { data->error = -EILSEQ; <-- NULL deref ... } If either bit is set in qstatus while host->data is NULL, the kernel will crash inside the IRQ handler. smatch flags this: drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we previously assumed 'data' could be null (see line 914) Gate both branches on a non-NULL data, matching the existing pattern used by the DATDNE branch. No functional change for callers where data is non-NULL, which is the only case in which these branches did meaningful work before this change.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97506", "url": "https://ubuntu.com/security/CVE-2026-97506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ixp4xx - fix buffer chain unwind on allocation failure chainup_buffers() builds a linked list of buffer descriptors for a scatterlist. If dma_pool_alloc() fails while constructing the list, the current code sets buf to NULL and later dereferences it unconditionally at the end of the function: buf->next = NULL; buf->phys_next = 0; This can lead to a null-pointer dereference on allocation failure. If the failure happens after part of the descriptor chain has already been allocated and DMA-mapped, the partially constructed chain also needs to be released. Fix this by terminating the partially constructed chain on allocation failure and letting the callers unwind it via their existing cleanup paths. Also fix ablk_perform() to preserve the hook pointers before checking for failure, so partially built chains can be freed correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97507", "url": "https://ubuntu.com/security/CVE-2026-97507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dm1105: fix missing error check for dma_alloc_coherent The return value of dm1105_dma_map(), which handles DMA memory allocation, is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver will proceed using a NULL pointer for DMA transfers, leading to a kernel oops or invalid hardware access. Fix this by checking the return value and propagating -ENOMEM on failure.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97508", "url": "https://ubuntu.com/security/CVE-2026-97508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Set tb->root_switch to NULL when domain is stopped Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97509", "url": "https://ubuntu.com/security/CVE-2026-97509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Keep XDomain reference during the lifetime of a service This is needed because we release the service ID in tb_service_release() and the ID array is owned by the parent XDomain.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97510", "url": "https://ubuntu.com/security/CVE-2026-97510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Release request if tb_cfg_request() fails in __tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97512", "url": "https://ubuntu.com/security/CVE-2026-97512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM The runtime PM functions had incomplete error handling that could leave the system in an inconsistent state. If any operation failed midway through suspend or resume, some resources would be left in the wrong state while others were already changed, leading to potential clock/power imbalances. Reorder the suspend/resume sequences to avoid brownout risk by ensuring the performance state is set appropriately before clocks are enabled and clocks are disabled before dropping the performance state. Fix by adding proper error checking for all operations and using goto-based cleanup to ensure all successfully acquired resources are properly released on any error.", "cve_priority": "low", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97516", "url": "https://ubuntu.com/security/CVE-2026-97516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result() It was recently reported that rtw_fw_adaptivity_result() in fw.c dereferences rtwdev->chip->edcca_th without a NULL check. The issue is that devices with the 8821CE chip don't define edcca_th in their chip info. As a result, when rtw_fw_adaptivity_result() tries to dereference it, the kernel triggers an oops. Add a NULL check for edcca_th before dereferencing it in rtw_fw_adaptivity_result() in fw.c. Placing the check at the function entry avoids logging any garbage values. This change does not address the root cause for this behavior, but it prevents the NULL dereference and the resulting oops while a more permanent solution is developed. Tested on a 8822CE chip which defines edcca_th, so this issue is not present on it, but it still uses this driver and I can verify there are no regressions.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-97517", "url": "https://ubuntu.com/security/CVE-2026-97517", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject beacons with bad HE operation The HE operation element not only needs to be longer than the fixed part, but also have an appropriate size for the variable part inside of it. Check this.", "cve_priority": "medium", "cve_public_date": "2026-09-24 17:17:00 UTC" }, { "cve": "CVE-2026-90053", "url": "https://ubuntu.com/security/CVE-2026-90053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent. The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification. htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping. Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90054", "url": "https://ubuntu.com/security/CVE-2026-90054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: \t/* tcp_write_xmit() */ \tlimit = mss_now; \tif (tso_segs > 1 && !tcp_urg_mode(tp)) \t\tlimit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: \t/* __tcp_retransmit_skb() */ \tlen = cur_mss * segs;\t\t/* segs > 1, no urg_mode check */ \t... \t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: \tseg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) \tseg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) \tseg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90055", "url": "https://ubuntu.com/security/CVE-2026-90055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90056", "url": "https://ubuntu.com/security/CVE-2026-90056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90057", "url": "https://ubuntu.com/security/CVE-2026-90057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference freed memory. Line discipline close() is already guaranteed to be called under the write lock of tty->ldisc_sem during hangup processing (in tty_ldisc_reinit() or tty_ldisc_kill()). Remove slip_hangup() so teardown is serialized cleanly by slip_close().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90058", "url": "https://ubuntu.com/security/CVE-2026-90058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by vega@nebusec.ai. Cap the final qdisc_pkt_len() to QDISC_PKT_LEN_MAX so the size-table amplification cannot drive deficit schedulers into an unbounded loop. A legitimate size table (e.g. qfq's overhead 999999999, which is handled by dropping) is still accepted. Introduce cap QDISC_PKT_LEN_MAX (1 << 20) = 1 MiB which is well above any legitimate single-skb wire length: the largest current skb->len is GSO_MAX_SIZE (524280), and an ATM-style size table (53/48 cell tax) amplifies that to ~578 KB, both comfortably below 1 MiB. At the same time, 1 MiB bounds the deficit refill loop to ~1M iterations per packet with quantum=1, which completes in a few milliseconds well under the demonstrated softlockup threshold (~10^9 iterations). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_NET_SCH_DRR=y (or CONFIG_NET_SCH_ETS=y). - Attach a DRR (or ETS) root qdisc with a crafted TCA_STAB that amplifies qdisc_pkt_len to ~1 GiB (e.g. size_log=15, data=[32768]). - Add a class with a tiny quantum of 1 and send one small packet; the deficit loop spins billions of times under the qdisc lock and trips the softlockup detector (panic with kernel.softlockup_panic=1). - Reachable as root or from an unprivileged user in a fresh user+net namespace (unshare -Urn) with namespace-local CAP_NET_ADMIN.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90060", "url": "https://ubuntu.com/security/CVE-2026-90060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90062", "url": "https://ubuntu.com/security/CVE-2026-90062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90063", "url": "https://ubuntu.com/security/CVE-2026-90063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90066", "url": "https://ubuntu.com/security/CVE-2026-90066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference. Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90067", "url": "https://ubuntu.com/security/CVE-2026-90067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at ceph_con_v2_try_read+0x6634/0x6810 net/ceph/messenger_v2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: ceph_con_workfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (`server_feat` and `server_req_feat`). Therefore, `payload_len` must be at least 16 bytes. Fix this by adding a check in `process_banner_prefix()` to reject a `payload_len` smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90068", "url": "https://ubuntu.com/security/CVE-2026-90068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two shifts, and its second channel looks accidental, but the control does report two values. Writing three into it reads off the end of adav80x_mux_values. The core catches that only under CONFIG_SND_CTL_INPUT_VALIDATION, which defaults off.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90070", "url": "https://ubuntu.com/security/CVE-2026-90070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or error path instead of acting on an invalid status value. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90071", "url": "https://ubuntu.com/security/CVE-2026-90071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) 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 (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: 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:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90072", "url": "https://ubuntu.com/security/CVE-2026-90072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90073", "url": "https://ubuntu.com/security/CVE-2026-90073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare \"tc qdisc add ... hhf\" succeeds with a clamped quantum but \"tc qdisc add ... hhf limit 1000\" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90074", "url": "https://ubuntu.com/security/CVE-2026-90074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90075", "url": "https://ubuntu.com/security/CVE-2026-90075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests \"*backlog <= params->mtu\"; with mtu == 0x80000000 (~2 GiB) and the default 32 MiB memory_limit, the test is always true, so CoDel is silently and completely disabled (no drops, no ECN). Declare a single clamped mtu and assign both q->quantum and q->cparams.mtu from it, which also removes the double psched_mtu() call. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90076", "url": "https://ubuntu.com/security/CVE-2026-90076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90078", "url": "https://ubuntu.com/security/CVE-2026-90078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: fix length calculations and avoid invalid header warnings syzbot reported a warning in skb_network_header_len() triggered by tcf_skbmod_act(): !skb_transport_header_was_set(skb) WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline] WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55 There are a few issues in tcf_skbmod_act(): 1. Calling skb_network_header_len() assumes skb->transport_header is set, which is not guaranteed when tcf_skbmod_act() runs at TC ingress. 2. Unconditionally calling skb_mac_header_len() at the beginning of tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the MAC header is unset, evaluating to an underflowed garbage length. 3. On TC ingress, skb->data points to the network header. Adding the MAC header length to the IP header length causes skb_ensure_writable() to request more bytes than the actual IP packet length, dropping valid short packets (e.g. 28-byte UDP/IPv4 packets). Fix these by: - Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for SKBMOD_F_ECN so that the required length is correctly calculated on both ingress (offset == 0) and egress (offset == mac_len). - Setting max_edit_len to ETH_HLEN for Ethernet header modifications after validating ARPHRD_ETHER.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90081", "url": "https://ubuntu.com/security/CVE-2026-90081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-89780", "url": "https://ubuntu.com/security/CVE-2026-89780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: restore skb->dev on deaggregated frames rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns skb->dev = ep->egress_dev only on the data path, but a MAP command frame is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack() runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user reaches this by unsharing a user+net namespace, creating an rmnet link over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS, and writing an aggregated frame carrying a flow-control command to the tap fd. Restore the assignment dropped by 378e25357ac7, so every skb leaving rmnet_map_deaggregate() has a valid device. BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158) Write of size 4 at addr 00000000000004b4 by task exploit/144 Call Trace: _raw_spin_lock (kernel/locking/spinlock.c:158) netif_tx_lock (net/sched/sch_generic.c:497) rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6103) ... __netif_receive_skb_one_core (net/core/dev.c:6214) netif_receive_skb (net/core/dev.c:6474) tun_get_user (drivers/net/tun.c:1966) tun_chr_write_iter (drivers/net/tun.c:2012) vfs_write (fs/read_write.c:687) ksys_write (fs/read_write.c:739) 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": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89789", "url": "https://ubuntu.com/security/CVE-2026-89789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free gtp_newlink()'s error path frees tid_hash and addr_hash without waiting for an RCU grace period after clearing sk_user_data. A concurrent gtp_encap_recv() in softirq may still hold the gtp_dev pointer obtained via rcu_dereference_sk_user_data() and access the freed memory. BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152) Call Trace: gtp0_pdp_find+0x1f6/0x200 gtp_encap_recv+0x527/0x24b0 udp_queue_rcv_one_skb+0x75f/0xc10 Add synchronize_net() before the kfree calls in out_hashtable, which covers all error paths from both gtp_encap_enable() and gtp_create_sockets().", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90088", "url": "https://ubuntu.com/security/CVE-2026-90088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:16:00 UTC" }, { "cve": "CVE-2026-90090", "url": "https://ubuntu.com/security/CVE-2026-90090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: \terr = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, \t\t\t round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which \"Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX\" ensures.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90091", "url": "https://ubuntu.com/security/CVE-2026-90091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90092", "url": "https://ubuntu.com/security/CVE-2026-90092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90101", "url": "https://ubuntu.com/security/CVE-2026-90101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix call to hardware monitoring event handler The first parameter of hwmon_notify_event() is supposed to be the hardware monitoring device. The bnxt driver calls it with the platform device as first parameter instead. This API break results in undefined behavior and may result in a crash. Pass the hardware monitoring device as parameter instead to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90102", "url": "https://ubuntu.com/security/CVE-2026-90102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pnfs: key the data server cache on the NFS version nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath address set alone, and struct nfs4_pnfs_ds records no version. That suffices for the files layout driver, which always connects with version 4, but flexfiles takes its version tuple from GETDEVICEINFO per device, and one address can legitimately serve both NFSv3 and NFSv4. Two deviceids on one address with different ds_versions[0].version therefore share a single nfs4_pnfs_ds, and whichever mirror connects first pins ds_clp to its own version. The other one is handed that client anyway, so it selects rpc_call_ops for a version the connection does not speak, and the mismatched sequence-slot handling dereferences NULL. Add the version to the cache key so the two cannot alias, giving each version its own nfs4_pnfs_ds and connection while both mirrors stay usable. Only the major version is compared, since that is what selects rpc_call_ops and rpc_ops; v4.0 and v4.1 keep sharing a client. The files layout driver passes the 4 it already hardcodes at connect time.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90103", "url": "https://ubuntu.com/security/CVE-2026-90103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix LAYOUTSTATS send buffer exhaustion encode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE), i.e. 256 bytes, for the layoutupdate4 body written by the layout driver. The flexfiles record can exceed that. ff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4, an nfs_fh4, two ff_io_latency4, an nfstime4 and a bool. A data server whose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of those bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4 and the bool add a further 144, so the body passes 256 bytes before the netaddr4 is encoded at all. encode_layoutstats() additionally writes the deviceid4 and the layoutupdate4 lou_type word, neither of which the macro accounts for. The filehandle and the address are both chosen by the server, through LAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the end of the send buffer. xdr_reserve_space() returns NULL once that happens, and the two ff_layout_encode_io_latency() calls run with dss_info->mirror->lock held, so a NULL return there leaves the lock permanently held. Raise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the reservation.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90107", "url": "https://ubuntu.com/security/CVE-2026-90107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free pending qentry in smc_llc_flow_stop() before memset smc_llc_flow_stop() resets a flow struct with a blind memset: \tspin_lock_bh(&lgr->llc_flow_lock); \tmemset(flow, 0, sizeof(*flow)); \tflow->type = SMC_LLC_FLOW_NONE; \tspin_unlock_bh(&lgr->llc_flow_lock); If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object. A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct. Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90108", "url": "https://ubuntu.com/security/CVE-2026-90108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to ADD_LINK transition When smc_llc_event_handler() transitions the local LLC flow from SMC_LLC_FLOW_REQ_ADD_LINK to SMC_LLC_FLOW_ADD_LINK on arrival of an ADD_LINK request, it calls smc_llc_flow_qentry_set() unconditionally: \tif (lgr->llc_flow_lcl.type == SMC_LLC_FLOW_REQ_ADD_LINK) { \t\tlgr->llc_flow_lcl.type = SMC_LLC_FLOW_ADD_LINK; \t\tsmc_llc_flow_qentry_set(&lgr->llc_flow_lcl, qentry); \t\t... \t} A CONFIRM_LINK or ADD_LINK_CONT arriving while flow->type is SMC_LLC_FLOW_REQ_ADD_LINK is stashed into flow->qentry via the SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADD_LINK arrives, the REQ_ADD_LINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object. The stashed entry has no consumer: smc_llc_wait() is only called from llc_add_link_work, which is not yet scheduled while the flow type remains REQ_ADD_LINK. No waiter is sleeping on llc_msg_waiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite. Call smc_llc_flow_qentry_del() before smc_llc_flow_qentry_set() in the REQ_ADD_LINK branch. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90109", "url": "https://ubuntu.com/security/CVE-2026-90109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit: sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ) gred_backlog+qdisc_pkt_len(skb) <= q->limit (gred configured VQ) sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo) sch->qstats.backlog + skb->len <= q->limit (plug) sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM. Promote the sums to u64 so admission stops once the true backlog exceeds the limit. The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps. The bug can only be reproduced as root (albeit with ridiculous setup): attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB, leaving the default VQ unconfigured (for gred), and drive >4 GiB of queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len, or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32, admission keeps succeeding, and the queue grows unboundedly to OOM.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90110", "url": "https://ubuntu.com/security/CVE-2026-90110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inetpeer: randomize RB-tree node comparison using SipHash The inetpeer rate limiting system stores peer entries in a Red-Black tree keyed deterministically on the remote IP address. Because tree lookups walk the RB-tree using standard lexicographical comparisons (inetpeer_addr_cmp), an off-path adversary can predict the exact topology of the tree and the sequence of nodes traversed during lookups (the gc_stack candidate list). By combining deterministic tree traversal with aggressive garbage collection (triggered when tree size exceeds inet_peer_threshold), an attacker can selectively force the eviction of targeted inet_peer nodes. When an evicted node is subsequently re-created upon receiving a new packet, its rate-limiting token bucket (rate_tokens, rate_last) is reset to full capacity. This creates a side-channel primitive allowing off-path attackers to bypass IP-keyed ICMP rate limits and infer open UDP ports (similar to SAD DNS style attacks). Mitigate this by randomizing the RB-tree node comparison logic using SipHash with a secret key (inetpeer_hash_key) initialized via net_get_random_once(). Nodes are ordered in the tree by SipHash(addr, key) rather than raw IP addresses. Because the secret key is unknown to external entities, the tree layout and lookup traversal paths are unpredictable to off-path adversaries, breaking the deterministic eviction gadget. Cache the computed 64-bit SipHash (hash) in struct inet_peer and compute the target hash (dhash) once at the beginning of inet_getpeer() to avoid recomputing SipHash at every step of the RB-tree walk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90112", "url": "https://ubuntu.com/security/CVE-2026-90112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlcnic: validate unified ROM sections before loading The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file. Existing validation forms table and data ends with unchecked additions and multiplications. Malformed values can wrap before they are compared with the firmware size. The parser also dereferences typed pointers at firmware-controlled offsets. Valid descriptor extents alone are insufficient for the consumers. The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64. A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading. Replace the pointer-returning parser with bounded range helpers. Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain. Apply the same range checks to the legacy image before reading its fixed fields.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90114", "url": "https://ubuntu.com/security/CVE-2026-90114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: Reject descending VLAN tunnel ranges A pair of descending VLAN and tunnel IDs can pass the tunnel range span check. The VLAN subtraction produces a negative int, which is converted to unsigned when compared with the u32 tunnel ID subtraction. It can therefore equal the wrapped tunnel ID delta. The range loop then performs no iterations. Since the batched notification handling added a post-loop error check, this leaves err uninitialized and makes the request's return value unpredictable. Reject descending VLAN ranges before comparing the spans. Valid ascending and single-entry ranges remain unchanged, while malformed descending ranges consistently return -EINVAL. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90115", "url": "https://ubuntu.com/security/CVE-2026-90115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: fix NULL pointer dereference in __xsk_rcv() In the __xsk_rcv() multi-buffer path, xsk_buff_alloc() is called in a loop without checking its return value. xsk_buff_can_alloc() only counts fill queue entries without validating their addresses, so it can succeed while xsk_buff_alloc() rejects all remaining entries and returns NULL. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__xsk_rcv+0x426/0xc20 (net/xdp/xsk.c:350) Call Trace: xsk_generic_rcv+0x26d/0x5f0 xdp_do_generic_redirect+0x3c5/0xcf0 do_xdp_generic+0x92f/0xe70 __netif_receive_skb_core.constprop.0+0xf7e/0x2b30 Fix this with a two-stage transaction. First allocate and stage all buffers required for the packet, recycling all staged buffers with xsk_buff_free() if any allocation fails. Only after this stage succeeds, copy the data, reserve the RX descriptors, and release the buffers in an error-free loop.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90119", "url": "https://ubuntu.com/security/CVE-2026-90119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails. Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90122", "url": "https://ubuntu.com/security/CVE-2026-90122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: visconti: Make sure clk_init_data is fully initialized The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. visconti_clk_register_gate() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90124", "url": "https://ubuntu.com/security/CVE-2026-90124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-rzg2l: Fix loss of interrupt rzg2l_clear_irq_int() and rzg2l_clear_tint_int() perform a read-modify-write on the ISCR/TSCR status registers to clear the bit for the interrupt just handled. Since these registers are write-0-to-clear per bit, this is racy: If another interrupt's status bit gets set between the read and the write, that bit is written back as 0 by the software-constructed value, clearing an interrupt that hasn't been serviced yet and losing it. This can be reproduced by triggering multiple interrupts at once, e.g.: gpioset -c gpiochip0 355=0 353=0 328=0 352=0 Fix this by writing back only the bit being cleared, with all other bits set to 1, instead of read-modify-writing the whole register. Since 1-bits are left unchanged by hardware, concurrently-set status bits for other interrupts are preserved.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90125", "url": "https://ubuntu.com/security/CVE-2026-90125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix request buffer leak in smb2_new_read_req() smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between: \trc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, \t\t\t\t (void **) &req, total_len); \tif (rc) \t\treturn rc; \tif (server == NULL) \t\treturn -ECONNABORTED; \t[...] \t\trdata->mr = smbd_register_mr(server->smbd_conn, \t\t\t\t\t &rdata->subreq.io_iter, \t\t\t\t\t true, need_invalidate); \t\tif (!rdata->mr) \t\t\treturn -EAGAIN; On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case. The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning: \twdata->mr = smbd_register_mr(...); \tif (!wdata->mr) { \t\trc = -EAGAIN; \t\tgoto async_writev_out; \t} Commit b7972092199f (\"cifs: smbd: Retry on memory registration failure\") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other. Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident. Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting. Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata. The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90126", "url": "https://ubuntu.com/security/CVE-2026-90126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: pcf8563: fix clock provider leak on unbind pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90128", "url": "https://ubuntu.com/security/CVE-2026-90128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: fix wrong list iterated in add_direct_chain error path In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90130", "url": "https://ubuntu.com/security/CVE-2026-90130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: fix cleanup after worker creation failure vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90135", "url": "https://ubuntu.com/security/CVE-2026-90135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs() sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 (\"net: add net device refcount tracker infrastructure\") added ref_tracker_dir_exit() to only free_netdev() path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90137", "url": "https://ubuntu.com/security/CVE-2026-90137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix password encoding bounds check The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90138", "url": "https://ubuntu.com/security/CVE-2026-90138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: don't check the listener's sk_err in vsock_accept() Syzbot reported an issue which can be reproduced with these steps: \tr0 = socket(AF_VSOCK, SOCK_STREAM, 0) \tbind(r0, {VMADDR_CID_ANY, PORT}) \tconnect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) \tlisten(r0, backlog) -> 0 \tr1 = socket(AF_VSOCK, SOCK_STREAM, 0) \tconnect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 \taccept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90139", "url": "https://ubuntu.com/security/CVE-2026-90139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: check for NULL root inode in fuse_fill_super_submount fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace: fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89779", "url": "https://ubuntu.com/security/CVE-2026-89779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate ef->size covers the record's name and value When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-89781", "url": "https://ubuntu.com/security/CVE-2026-89781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read in read_log_rec_buf() read_log_rec_buf() copies a log record into a caller buffer starting at \tu32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. \"tail = log->page_size - off\" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90140", "url": "https://ubuntu.com/security/CVE-2026-90140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cuse: wait for pending RCU callbacks on module exit Since commit 053fc4f755ad (\"fuse: fix UAF in rcu pathwalks\"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89776", "url": "https://ubuntu.com/security/CVE-2026-89776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address attributes as NLA_BINARY with only a maximum length, so validate_nla() accepts a payload shorter than the address. The GROUP consumer reads it with nla_get_in_addr(), an unconditional 4-byte load, so a short attribute over-reads up to 3 bytes of uninitialised slab data, which are stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing kernel memory. Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is always sent at full width.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90141", "url": "https://ubuntu.com/security/CVE-2026-90141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix integer overflow in ftp helper port/address parsing ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16 (hport) and into unsigned char (p[]) without checking for overflow. A crafted FTP PASV/EPSV response with an over-long port or address octet wraps the value, so the helper configures the data connection with a truncated port/address. The netfilter conntrack FTP helper had the same defect, fixed in commit 2b413fc689ba (\"netfilter: nf_conntrack_ftp: avoid u16 overflows\"). Apply the equivalent fix here: widen the port accumulator to u32 and reject values above 65535, and reject address octets above 255.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90143", "url": "https://ubuntu.com/security/CVE-2026-90143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: kcm: Hold RCU read lock while running BPF parser kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which prevents CPU migration, but does not establish an RCU read-side critical section. Consequently, BPF map operations can trigger WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser program. Hold the RCU read lock while running the program.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90148", "url": "https://ubuntu.com/security/CVE-2026-90148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease() When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease().", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90150", "url": "https://ubuntu.com/security/CVE-2026-90150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/blocklayout: Fix device leaks on parse failure bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn. If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero. Release the failed child and the already parsed children before returning the error. Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly. bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference. Clear the pointer after fput() so that an outer cleanup path does not put it again.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90151", "url": "https://ubuntu.com/security/CVE-2026-90151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: remove callback IDR entry on client allocation failure nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown. A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it. Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client. This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90152", "url": "https://ubuntu.com/security/CVE-2026-90152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix session leak in ksmbd_session_register() See the procedure below: smb2_sess_setup ksmbd_smb2_session_create __session_create atomic_set(&sess->refcnt, 2) hash_add(sessions_table, &sess->hlist, sess->id) ksmbd_session_register xa_store(&conn->sessions, sess->id, sess) // fail ksmbd_user_session_put atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed Remove the session from sessions_table and drop its table reference if xa_store() fails.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90153", "url": "https://ubuntu.com/security/CVE-2026-90153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size). When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks. A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size. Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server. Validation: - semantic KUnit harness shows the post-boundary ACE is selected before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90157", "url": "https://ubuntu.com/security/CVE-2026-90157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative optlen in cgroup getsockopt hook A cgroup getsockopt BPF program can shrink ctx->optlen after the kernel getsockopt handler has run. The kernel-buffer variant, used by TCP_ZEROCOPY_RECEIVE, only rejects values larger than the original length. If BPF writes a negative optlen, that value is accepted and propagated back to the TCP getsockopt code. It can then be passed to copy_to_sockptr() as a size_t and trigger the hardened usercopy bytes > INT_MAX warning. Reject negative ctx.optlen in __cgroup_bpf_run_filter_getsockopt_kern(), matching the lower-bound validation already present in the sockptr-based getsockopt hook.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90158", "url": "https://ubuntu.com/security/CVE-2026-90158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: m68k: nfcon: Do not call console_is_registered() in nfcon_device() Since 7c2af0f634f1 (\"tty: tty_io: use console_list_lock for list synchronization\") show_cons_active() calls the .device() method under the console_list_lock, but console_is_registered() tries to acquire console_list_lock as well, causing a deadlock. It should not be necessary to check console_is_registered() here since the function should not be called in the fist place when the console is not registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90159", "url": "https://ubuntu.com/security/CVE-2026-90159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks _bpf_setsockopt() and _bpf_getsockopt() call sock_owned_by_me() for full sockets, so these helpers expect the socket lock to be held. BPF_CGROUP_UNIX_GETPEERNAME and BPF_CGROUP_UNIX_GETSOCKNAME run BPF programs without acquiring the socket lock. A program attached to either hook can therefore trigger the sock_owned_by_me() warning by calling bpf_setsockopt() or bpf_getsockopt(). Disallow bpf_setsockopt() and bpf_getsockopt() for CGROUP_UNIX_GETPEERNAME and CGROUP_UNIX_GETSOCKNAME.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90160", "url": "https://ubuntu.com/security/CVE-2026-90160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lwt_bpf: Restore reserved headroom after xmit program ip_finish_output2() expands an skb to LL_RESERVED_SPACE(dev) before LWT xmit. An LWT_XMIT BPF program can then modify the skb head and still return BPF_OK, so bpf_xmit() rechecks the remaining headroom before the skb continues to neighbour output. That recheck uses dst->dev->hard_header_len. This is not enough for the neighbour cached-header path: neigh_hh_output() copies the cached hardware header using the aligned hh_cache size, HH_DATA_MOD for short headers or HH_DATA_ALIGN(hh_len) otherwise. On Ethernet, hard_header_len is 14 but the cached copy needs 16 bytes. If an LWT_XMIT BPF program calls bpf_skb_change_head(skb, 1, 0), the skb can still have 15 bytes of headroom after the program. The existing check accepts that, after which neigh_hh_output() hits its headroom warning and drops the skb. Use LL_RESERVED_SPACE(dst->dev) in the post-BPF headroom check to match the reservation made before LWT xmit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90166", "url": "https://ubuntu.com/security/CVE-2026-90166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request() See the procedure below: ksmbd_tree_conn_connect ksmbd_share_config_get share->name = kstrdup() // fail if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false // do not check `share->name` ksmbd_ipc_tree_connect_request strlen(share->name) // null-ptr-deref", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90169", "url": "https://ubuntu.com/security/CVE-2026-90169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: free preauth sessions on connection teardown SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object. Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90170", "url": "https://ubuntu.com/security/CVE-2026-90170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90175", "url": "https://ubuntu.com/security/CVE-2026-90175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer Free it unconditionally after ksmbd_alloc_user() calls. kmemleak splat: unreferenced object 0xffff888103b83540 (size 192): comm \"pool-0\", pid 16970, jiffies 4377290937 hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 408ccc66): __kvmalloc_node_noprof+0x730/0x920 handle_generic_event+0xec/0x1a0 [ksmbd] genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x181/0x290 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x1e6/0x2c0 netlink_sendmsg+0x20a/0x450 ____sys_sendmsg+0x2e8/0x310 ___sys_sendmsg+0x78/0xc0 __sys_sendmsg+0x63/0xc0 do_syscall_64+0xa1/0x670 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90176", "url": "https://ubuntu.com/security/CVE-2026-90176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90178", "url": "https://ubuntu.com/security/CVE-2026-90178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix core_data leak on CPUs without PTS pdata->core_data is allocated in init_temp_data() when the first core temp_data of a package is created, but it is only released from destroy_temp_data(), and only in the branch that handles the package temp_data. Package temp_data is created solely when the CPU supports X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL. coretemp_cpu_offline() then skips the removal of the package interface, destroy_temp_data() is never called for package data, and the array is still allocated when coretemp_device_remove() frees the platform data that pointed at it. Release the array in coretemp_device_remove(). destroy_temp_data() sets pdata->core_data to NULL when it frees it, so the added kfree() is a no-op on CPUs that do have PTS. Tested on an Intel Core i5-1135G7. The driver was instrumented to log every allocation and release of pdata->core_data, and the PTS check in coretemp_cpu_online() was patched out to emulate a CPU without package thermal support. Without this change the array was allocated and never released, and coretemp_device_remove() still saw a non-NULL pointer. With it the array is released and the pointer accounting balances. On an unmodified build the release still happens via the package temp_data and the added kfree() sees NULL, with no slab warnings over repeated module load and unload cycles.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90180", "url": "https://ubuntu.com/security/CVE-2026-90180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mtip32xx: synchronize ioctls with device removal The ioctl handlers only test REMOVE_PENDING before entering mtip_hw_ioctl(). Removal can set that bit immediately afterwards and free dd->port in mtip_hw_exit() while an ioctl still dereferences it. An already open block device can reach the handlers while del_gendisk() is in progress. Serialize both native and compat ioctls with removal. Set REMOVE_PENDING before taking the mutex so new callers fail after an in-flight ioctl has drained, and hold the mutex until the port has been torn down.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90184", "url": "https://ubuntu.com/security/CVE-2026-90184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute updates with device setup The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used. null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources: CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones() blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO: WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560 Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write. Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves. Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90185", "url": "https://ubuntu.com/security/CVE-2026-90185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under \"lock\" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take \"lock\" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90186", "url": "https://ubuntu.com/security/CVE-2026-90186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: reject per-device queue resize for shared tag set When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value. Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing at those NULLed hctx slots. blk_mq_map_swqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blk_mq_map_swqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] [ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0 [ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10 [ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk] [ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk] [ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk] [ 460.231776] ? configfs_write_iter+0x35c/0x4e0 [ 460.232122] configfs_write_iter+0x286/0x4e0 [ 460.232460] vfs_write+0x52d/0xd00 [ 460.232779] ? __x64_sys_openat+0x108/0x1d0 [ 460.233106] ? __pfx_vfs_write+0x10/0x10 [ 460.233413] ? fdget_pos+0x1cf/0x4c0 [ 460.233745] ? fput_close+0x133/0x190 [ 460.234038] ? __pfx_expand_files+0x10/0x10 [ 460.234368] ksys_write+0xfc/0x1d0 Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90187", "url": "https://ubuntu.com/security/CVE-2026-90187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free zones array on device power-off null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle. Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call. And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90188", "url": "https://ubuntu.com/security/CVE-2026-90188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: free global tag_set on init error path If shared_tags is enabled, null_setup_tagset() allocates the global tag_set via null_init_global_tag_set(). If device creation later fails, err_dev destroys the default devices and calls unregister_blkdev(), but never frees the global tag_set. Since module init failed, null_exit() is never invoked, so the global tag_set's tags and maps are permanently leaked. Free the global tag_set in err_dev, matching null_exit() which does if (tag_set.ops) blk_mq_free_tag_set(&tag_set).", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90189", "url": "https://ubuntu.com/security/CVE-2026-90189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: register configfs subsystem after creating default devices In null_init(), configfs_register_subsystem() currently runs before register_blkdev(), so when null_blk is built as a module, a racing mkdir() + poweron from userspace can reach null_add_dev() while null_major is still 0. __add_disk() then hits WARN_ON(disk->minors) (major=0 with minors!=0) and fails: [root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at __add_disk+0x8a7/0xde0, [ 2366.523552] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] [ 2366.547831] ? _raw_spin_lock+0x84/0xe0 [ 2366.548260] add_disk_fwnode+0x114/0x560 [ 2366.548739] null_add_dev+0x102d/0x1b80 [null_blk] [ 2366.549310] ? __pfx_null_add_dev+0x10/0x10 [null_blk] [ 2366.549906] ? mutex_lock+0xde/0x1c0 [ 2366.550361] ? __pfx_mutex_lock+0x10/0x10 [ 2366.550827] nullb_device_power_store+0x1e7/0x280 [null_blk] [ 2366.551499] ? __pfx_nullb_device_power_store+0x10/0x10 [null_blk] [ 2366.552177] ? __kmalloc_cache_noprof+0x1f5/0x470 [ 2366.552748] ? configfs_write_iter+0x35c/0x4e0 [ 2366.553242] configfs_write_iter+0x286/0x4e0 [ 2366.553787] vfs_write+0x52d/0xd00 [ 2366.554169] ? __pfx_vfs_write+0x10/0x10 [ 2366.554679] ? __pfx___css_rstat_updated+0x10/0x10 [ 2366.555196] ? fdget_pos+0x1cf/0x4c0 [ 2366.555649] ksys_write+0xfc/0x1d0 ...... Additionally, the err_dev path destroys all devices on nullb_list while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, null_destroy_dev()->null_free_dev() kfrees the user device's nullb_device but /sys/kernel/config/nullb/ is still reachable. Any userspace access to the item will trigger a UAF. For simplicity, move configfs_register_subsystem() to the end to solve the problems above.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90190", "url": "https://ubuntu.com/security/CVE-2026-90190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: use DEFINE_MUTEX for the file-scope mutex In null_init(), mutex_init(&lock) currently happens after configfs_register_subsystem(), which exposes the nullb subsystem to userspace. A racing mkdir() into /sys/kernel/config/nullb/ can reach null_find_dev_by_name() -> mutex_lock(&lock) before the mutex is initialized, trigger warning: [ 123.137788] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 123.137796] WARNING: kernel/locking/mutex.c:159 at mutex_lock+0x171/0x1c0, CPU#13: mkdir/1301 [ 123.140090] Modules linked in: null_blk(+) nft_fib_inet nft_fib_ipv4 ...... [ 123.154926] Call Trace: [ 123.155172] [ 123.155419] ? __pfx_mutex_lock+0x10/0x10 [ 123.156181] ? __pfx__raw_spin_lock+0x10/0x10 [ 123.156571] nullb_group_make_group+0x20/0x100 [null_blk] [ 123.157011] configfs_mkdir+0x47b/0xc70 [ 123.157337] ? __pfx_configfs_mkdir+0x10/0x10 [ 123.157719] ? may_create_dentry+0x242/0x2e0 [ 123.158061] vfs_mkdir+0x2a9/0x6c0 [ 123.158352] filename_mkdirat+0x3dc/0x500 [ 123.158710] ? __pfx_filename_mkdirat+0x10/0x10 [ 123.159070] ? strncpy_from_user+0x3a/0x1d0 [ 123.159413] __x64_sys_mkdir+0x6b/0x90 [ 123.159760] do_syscall_64+0xea/0x600 Replace the runtime mutex_init(&lock) with a static DEFINE_MUTEX(lock) declaration to fix this issue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90194", "url": "https://ubuntu.com/security/CVE-2026-90194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: fix bus ID cleanup on device_add() failures When device_add() fails after acpi_device_set_name() has allocated an instance ID and a new acpi_device_bus_id has been linked into acpi_bus_id_list, the rollback path only removes wakeup_list and detaches the ACPI handle data. That leaves the bus-ID bookkeeping behind and keeps the allocated instance number consumed. Move the bus-ID cleanup and wakeup-list removal into a single helper. Use it from both the normal device teardown path and the device_add() rollback path. The wakeup list node is initialized before registration, so it can be deleted without checking whether the device is wakeup- capable like in the original teardown path. [ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ] [ rjw: Subject and changelog edits ]", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90196", "url": "https://ubuntu.com/security/CVE-2026-90196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: validate topology volume range before allocation SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90198", "url": "https://ubuntu.com/security/CVE-2026-90198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix use-after-free in snd_card_do_free() A use-after-free was detected in snd_card_do_free() when a sound card managed by devres is unbound while a user-space application still holds an open file descriptor. For managed cards, the memory is allocated using devres_alloc(), and its release function is set to __snd_card_release(), which calls snd_card_free(). When the device is unbound, the unbind thread calls snd_card_free(), which drops a reference to the card's device. If the user thread still has an open file descriptor, the reference count does not reach zero, and the unbind thread blocks on wait_for_completion(&released). When the user thread closes the file descriptor, it drops the final reference, invoking the device release callback release_card_device(), which calls snd_card_do_free(). snd_card_do_free() performs cleanup and calls complete(card->release_completion). This wakes up the unbind thread, which returns from snd_card_free() and __snd_card_release(). The devres core then immediately frees the memory block containing the snd_card structure. Meanwhile, the user thread continues execution in snd_card_do_free() and evaluates `if (!card->managed)`. It reads the `managed` boolean from the snd_card structure that was just freed by the unbind thread, triggering a KASAN use-after-free. Fix this by caching the value of card->managed in a local variable before calling complete(). This ensures that the card pointer is not dereferenced after the unbind thread has been woken up and potentially freed the card. BUG: KASAN: use-after-free in snd_card_do_free sound/core/init.c:604 [inline] BUG: KASAN: use-after-free in release_card_device+0x1ab/0x1b0 sound/core/init.c:153 Read of size 1 at addr ffff8881912ec909 by task syz-executor130/5857 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description+0x55/0x1e0 mm/kasan/report.c:378 print_report+0x58/0x70 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 snd_card_do_free sound/core/init.c:604 [inline] release_card_device+0x1ab/0x1b0 sound/core/init.c:153 device_release+0xc4/0x1f0 drivers/base/core.c:-1 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x222/0x550 lib/kobject.c:737 snd_card_file_remove+0x331/0x390 sound/core/init.c:1125 snd_pcm_release+0x12c/0x160 sound/core/pcm_native.c:2986 __fput+0x418/0xa50 fs/file_table.c:512 fput_close_sync+0x11f/0x240 fs/file_table.c:617 __do_sys_close fs/open.c:1511 [inline] __se_sys_close fs/open.c:1496 [inline] __x64_sys_close+0x7e/0x110 fs/open.c:1496 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 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90199", "url": "https://ubuntu.com/security/CVE-2026-90199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject out-of-range evcn in mi_enum_attr() In mi_enum_attr(), the start/end VCN validation for non-resident attributes is: \tif (svcn > evcn + 1) goto out; When evcn is U64_MAX the \"evcn + 1\" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected. VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range. However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing \"svcn > evcn + 1\" test still tolerates the sentinel (\"0 > 0\" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the \"evcn + 1\" wraparound. svcn does not need its own bound: once evcn < nbits, \"svcn > evcn + 1\" implies svcn <= nbits. [almaz.alexandrovich@paragon-software.com: fixed evcn check]", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90200", "url": "https://ubuntu.com/security/CVE-2026-90200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: \tif (mlcn * sct_per_clst >= sectors || \t mlcn2 * sct_per_clst >= sectors) \t\tgoto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in \tsbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90202", "url": "https://ubuntu.com/security/CVE-2026-90202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers _base_release_memory_pools() unconditionally frees every ioc->pcie_sg_lookup[] entry, including ones the setup loop never allocated after a partial failure, causing a \"bad dma\" warning on debug kernels or a NULL pointer dereference otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90203", "url": "https://ubuntu.com/security/CVE-2026-90203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90207", "url": "https://ubuntu.com/security/CVE-2026-90207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize input teardown with event_input snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): \tsnd_rawmidi_input_trigger(up=0) \t\t\t\t\tsnd_midi_input_event() \t\t\t\t\t -> snd_rawmidi_kernel_read() \t\t\t\t\t -> snd_rawmidi_input_trigger(up=1) \t -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: \tUnable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 \tCall trace: \t snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) \t snd_rawmidi_input_event_work+0x1c/0x2c \t process_one_work+0x150/0x3a4 \t worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad (\"ALSA: seq: midi: Serialize output teardown with event_input\") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90209", "url": "https://ubuntu.com/security/CVE-2026-90209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix deadlock during unregister Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90213", "url": "https://ubuntu.com/security/CVE-2026-90213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix memory leak in error path of build_tree() In the error path of build_tree(), node instances can remain in the local linked list when the function returns. Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head. Release the remaining node instances with for_each_fw_node() before returning to the caller.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90214", "url": "https://ubuntu.com/security/CVE-2026-90214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: fix stream_data leak on open error In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream. Free stream_data and clear the stream pointer on the error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90216", "url": "https://ubuntu.com/security/CVE-2026-90216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubi: Fix rollback for explicit UBI device numbers ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90218", "url": "https://ubuntu.com/security/CVE-2026-90218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix WARNING in res_to_rt syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via addr_handler() during asynchronous address resolution: \" WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ib_addr process_one_req RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: rdma_restrack_add+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addr_handler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 process_one_req+0x2eb/0x540 drivers/infiniband/core/addr.c:624 process_one_work kernel/workqueue.c:3375 [inline] process_scheduled_works+0xc4e/0x1630 kernel/workqueue.c:3458 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 \" In addr_handler(), cma_acquire_dev_by_src_ip() is called to populate id_priv->cma_dev and bind the associated ib_device to id_priv->id.device. If cma_acquire_dev_by_src_ip() returns an error (non-zero status), the ID remains unassociated with any RDMA device. Previously, rdma_restrack_add(&id_priv->res) was invoked unconditionally even when cma_acquire_dev_by_src_ip() failed, passing a resource with a NULL dev pointer and triggering the WARN_ON assertion in res_to_rt(). Fix this by only adding the resource to restrack when acquiring the device succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90219", "url": "https://ubuntu.com/security/CVE-2026-90219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Free debugfs on registration failure c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via setup_debugfs()), but it is removed only in c4iw_remove(), not in c4iw_dealloc(). When RDMA device registration fails, the registration worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing c4iw_remove(), so the debugfs dentries leak and outlive the freed c4iw_dev. Move debugfs_remove_recursive() into c4iw_dealloc() so every path that frees ctx->dev also removes its debugfs tree.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90220", "url": "https://ubuntu.com/security/CVE-2026-90220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Don't leak the extension cell pointer in the bounce payload The bounce_error_event() embeds the failed event in the bounce payload by pointing data.ext.ptr at it. When that event is a queued variable-length event, its own data.ext.ptr holds the address of its first extension cell, put there by snd_seq_event_dup(). The payload goes out verbatim through snd_seq_expand_var_event(), so the address reaches userspace. That is the same address commit 705dd6dcbc0e (\"ALSA: seq: Clear variable event pointer on read\") removed from the event header. The read path still clears it there, just above the call that expands the payload. Embed a sanitised copy instead, treated exactly as snd_seq_read() treats the header. A stack copy is enough because delivery is synchronous and snd_seq_event_dup() copies before returning. An unprivileged client reaches this by setting SNDRV_SEQ_FILTER_BOUNCE, queueing a variable-length event to a port that does not exist and reading the bounce back. Eight bytes on 64-bit, from its own pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90221", "url": "https://ubuntu.com/security/CVE-2026-90221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse the CORE_INIT_RSP packet without validating that the skb contains enough data. A malformed response (e.g. injected via virtual_ncidev) can declare a large num_supported_rf_interfaces while providing insufficient data, causing reads of uninitialized slab memory. This is later used in nci_init_complete_req(), triggering a KMSAN uninit-value warning. Add skb length checks before accessing packet fields: - Validate the skb has at least 1 byte for the status field. - Validate the skb can hold the fixed-size header before parsing. - In v2, bounds-check each variable-length rf_interface entry and its extension parameters within the parsing loop. - In v1, verify the skb is large enough for both the variable-length rf_interfaces array and the trailing rsp_2 structure.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90222", "url": "https://ubuntu.com/security/CVE-2026-90222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: hold a reference to the request skb during send_frame __pn533_send_async() publishes the command and then calls dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame can be matched to this command: the I2C threaded IRQ runs pn533_recv_frame(), which queues cmd_complete_work, and pn533_send_async_complete() frees cmd->req with consume_skb(). On the I2C transport, pn533_i2c_send_frame() still dereferences the same skb after i2c_master_send() returns, so a completion that races the send can free the skb while the transport is still using it. The request skb is owned by the command object and may be freed by command completion at any time after dev->cmd is published, so the transport send path must not assume it stays alive. Hold a temporary reference to the request skb across the send_frame() call so the transport always sees a live skb even if completion races the send. Add a pn533_send_cmd_frame() helper and use it from all three send paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90223", "url": "https://ubuntu.com/security/CVE-2026-90223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound SNL TLV parsing to the skb and add length checks nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length pair derived from skb->len, without bounding reads to the actual skb data. Three problems followed: - For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed. - The per-TLV header (type, length) was read without checking that two bytes remained. - A declared TLV length could run past the end of the buffer, and an SDREQ with length == 0 made \"service_name_len = length - 1\" underflow (size_t), driving an out-of-bounds read in the following strncmp() / nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3] without a length check. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Walk the TLV list by pointer, bounded by skb_tail_pointer() over the linear skb data, and validate each TLV declared length before use. Add explicit length checks for SDREQ (>= 1) and SDRES (exactly 2). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90224", "url": "https://ubuntu.com/security/CVE-2026-90224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix double completion race in nci_data_exchange_complete nci_close_device() and nci_rx_work can both call nci_data_exchange_complete() concurrently. After commit 4527025d440ce8 (\"nfc: nci: fix circular locking dependency in nci_close_device\") moved flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock), rx_work is no longer serialized with the explicit completion call in the close path. Both callers read the non-NULL callback pointer and invoke rawsock_data_exchange_complete(), which calls sock_put() -- but only one sock_hold() was taken, so the second sock_put() underflows the refcount and frees the socket while it is still in use. Replace the bare clear_bit(NCI_DATA_EXCHANGE) with test_and_clear_bit() so that only the first caller proceeds to invoke the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90225", "url": "https://ubuntu.com/security/CVE-2026-90225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90226", "url": "https://ubuntu.com/security/CVE-2026-90226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90227", "url": "https://ubuntu.com/security/CVE-2026-90227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed() Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor. Pass flags and open_for_write through and reject disallowed commands with -EACCES.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90228", "url": "https://ubuntu.com/security/CVE-2026-90228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns() When a host issues an Identify command with CNS 05h (I/O Command Set specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on req->ns->bdev. A file-backed namespace has no block device, so req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing. The I/O command set is selected by the host-supplied CSI field and the command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled, independent of the namespace backing type, so any file-backed namespace is exposed. Reject the command with Invalid Field when the namespace is not backed by a block device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90229", "url": "https://ubuntu.com/security/CVE-2026-90229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Destroy the admin queue on removal The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work(). This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before. Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl(). With this the following WARN followed by a panic no longer happens: WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blk_mq_release+0x194/0x238 lr : blk_mq_release+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blk_mq_release+0x194/0x238 (P) blk_put_queue+0x8c/0xf0 nvme_free_ctrl+0x4c/0x260 device_release+0x44/0x128 kobject_put+0xa0/0x120 put_device+0x1c/0x40 nvme_uninit_ctrl+0x48/0x60 apple_nvme_remove+0x54/0xb0 platform_remove+0x28/0x40 device_remove+0x54/0x98 device_release_driver_internal+ device_release_driver+0x20/0x38 apple_nvme_remove_dead_ctrl_wor process_one_work+0x1f4/0x770 worker_thread+0x1b8/0x360 kthread+0x140/0x160 ret_from_fork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):in_unlock_irqrestore+0x74/0x80 hardirqs last disabled at (448): [] el1_brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blk_mq_timeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpu_ref_tryget_many.cons lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90230", "url": "https://ubuntu.com/security/CVE-2026-90230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate() nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]). Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not. Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90235", "url": "https://ubuntu.com/security/CVE-2026-90235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere. When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers. Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.", "cve_priority": "negligible", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89784", "url": "https://ubuntu.com/security/CVE-2026-89784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6 rpcb_register_inet4() and rpcb_register_inet6() store the result of rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL. rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROC_SET encode path: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel. The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFP_KERNEL kstrdup() in rpc_sockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check. Mirror that handling: bail out with -ENOMEM when rpc_sockaddr2uaddr() returns NULL, before the address is fed into the encoder.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90245", "url": "https://ubuntu.com/security/CVE-2026-90245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: kyro: Validate overlay viewport coordinates The overlay viewport end coordinates are computed from the viewport origin and dimensions using 32-bit unsigned arithmetic. Large input values can cause these calculations to wrap around before the resulting coordinates are passed to SetOverlayViewPort(). SetOverlayViewPort() packs the viewport coordinates into 16-bit register fields. The X coordinates are additionally adjusted by +2 and +1 before being written. Validate the coordinate calculations for 32-bit wraparound and ensure that the adjusted coordinates fit within their 16-bit register fields before calling SetOverlayViewPort(). Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90248", "url": "https://ubuntu.com/security/CVE-2026-90248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: fix teardown of an adopted proto on insert-race loss In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90249", "url": "https://ubuntu.com/security/CVE-2026-90249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes The IIO core does not filter duplicate writes to the event enable attribute, so writing the same value twice invokes write_event_config() twice. Enabling twice leaks a runtime PM reference, preventing the device from ever suspending again; disabling twice underflows the usage count and triggers a \"Runtime PM usage count underflow\" warning. Bail out early when the requested state matches the current state. While at it, switch to pm_runtime_resume_and_get() so a failed resume is propagated to userspace instead of silently marking the event enabled.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90250", "url": "https://ubuntu.com/security/CVE-2026-90250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix storage null-ptr-deref after replacing prog Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90251", "url": "https://ubuntu.com/security/CVE-2026-90251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: \tif (skb->len < sizeof(*rp)) { \t\tbt_dev_err(hdev, \"MSFT supported features length mismatch\"); \t\tgoto failed; \t} evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so \tmsft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, \t\t\t\t GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes (\"skb->len=11 evt_prefix_len=255\", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with \"MSFT event prefix length mismatch\" and msft->evt_prefix is left unset.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90253", "url": "https://ubuntu.com/security/CVE-2026-90253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90254", "url": "https://ubuntu.com/security/CVE-2026-90254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: free the advertising instance on the failure and cancel paths adv_timeout_expire() hands a kmalloc()ed instance byte to hci_cmd_sync_queue() with a NULL destroy callback, and only adv_timeout_expire_sync() frees it. That leaks on two paths: - the return value is not checked, and hci_cmd_sync_queue() does not take ownership when it fails (-ENETDOWN, -ENODEV, -ENOMEM); - a cancelled entry is not released, as _hci_cmd_sync_cancel_entry() does not free entry->data when there is no destroy callback. hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. Free the buffer from a destroy callback, and in the caller when the entry could not be queued at all.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90255", "url": "https://ubuntu.com/security/CVE-2026-90255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 (\"Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks\"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90257", "url": "https://ubuntu.com/security/CVE-2026-90257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: avoid OOB read of build info string The virtbt_setup_zephyr() sends the Zephyr vendor command 0xfc08 (Read Build Information) and hands the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length. A backend that answers with status only leaves that pointer past the end of the received data, so the walk reads adjacent slab memory until it meets a NUL. Those bytes reach the kernel log and the firmware-info debugfs file. To fix this, print the string with a bounded \"%.*s\" limited to skb->len - 1. A short or unterminated response then prints as much as arrived instead of failing setup. This mirrors commit dd068ef04412 (\"Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\"), which fixed the identical pattern.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90262", "url": "https://ubuntu.com/security/CVE-2026-90262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: retry verity reads for not-uptodate Merkle folios btrfs_read_merkle_tree_page() can find a folio in the mapping that is not uptodate. After taking the folio lock, the current code treats that state as a read error and returns -EIO. That can make a previous transient read failure sticky. If the failed read left a not-uptodate folio in the mapping, later callers find that folio and fail instead of retrying the read. Keep the existing page-cache insertion and locking order, but retry the Merkle item read when a not-uptodate folio is found in the mapping. Also unlock the folio when read_key_bytes() fails so that a later caller can lock it and retry the read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90274", "url": "https://ubuntu.com/security/CVE-2026-90274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: etm4x: fix underflow for usage of (nrseqstate - 1) According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR is implemented only when TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000. IOW, the number of usage in the initialisation or setting TRCSEQEVR with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000. Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR relevant fields setup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90275", "url": "https://ubuntu.com/security/CVE-2026-90275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d (\"md: don't quiesce in mddev_suspend()\") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 (\"md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()\"), also triggered by b39f35ebe86d.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90279", "url": "https://ubuntu.com/security/CVE-2026-90279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: round bitmap stripes with sector division raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90280", "url": "https://ubuntu.com/security/CVE-2026-90280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90281", "url": "https://ubuntu.com/security/CVE-2026-90281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90282", "url": "https://ubuntu.com/security/CVE-2026-90282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend There is a small window where the runtime suspend callback may run after pm_runtime_enable() and before pm_runtime_forbid(). In this case, a crash occurs because runtime suspend/resume dereferences qmp->phy pointer, which is not yet initialized: `if (!qmp->phy->init_count) {` This can also happen if user re-enables runtime-pm via the sysfs attribute before qmp phy is initialized. Similarly to other qcom phy drivers, introduce a qmp->phy_initialized variable that can be used to avoid relying on the possibly uninitialized phy pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90283", "url": "https://ubuntu.com/security/CVE-2026-90283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90284", "url": "https://ubuntu.com/security/CVE-2026-90284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90285", "url": "https://ubuntu.com/security/CVE-2026-90285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path qla2x00_sysfs_read_vpd() called ha->isp_ops->read_optrom() a second time after releasing optrom_mutex. The repeated read is redundant and, unlike the first, runs without optrom_mutex held, exposing flash access to concurrent optrom operations. Drop the duplicate call.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90286", "url": "https://ubuntu.com/security/CVE-2026-90286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx6: Use PFP on the compute queues too On GFX6, the compute rings use the same CP path as the graphics ring. The only difference is that they don't support draw commands. (As opposed to GFX7 and newer which have a separate command parser that is called MEC for compute queues.) This means that we have to take into consideration that the PFP also exists on compute queues on GFX6: Use PFP for register writes on both graphics and compute queues. In the pipeline sync, use the PFP to wait for the previous fence (and not the ME) to prevent the PFP from starting to execute the next submission while the ME is still in the previous submission. After a VM flush, emit PFP_SYNC_ME on compute queues as well.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90287", "url": "https://ubuntu.com/security/CVE-2026-90287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: sunplus: fix error handling in sp_uphy_init() Fix the error paths of sp_uphy_init() to undo exactly what each stage did: return directly if clk_prepare_enable() fails, release only the clock if reset_control_deassert() fails, and jump to err_reset if update_disc_vol() fails so the clock and reset are not leaked.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90290", "url": "https://ubuntu.com/security/CVE-2026-90290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Restore DAIF state on error Sashiko AI has reported that if swsusp_mte_save_tags() for some reason fails we return from swsusp_arch_suspend() with DAIF being masked - that is not what we'd expect. Restore the saved DAIF state before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90291", "url": "https://ubuntu.com/security/CVE-2026-90291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: module/dups: Fix use-after-free in kmod_dup_req lifetime handling The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90292", "url": "https://ubuntu.com/security/CVE-2026-90292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix use-after-free in siw_accept() siw_accept() looks up the QP supplied by userspace. If that QP is already in RTS, the function jumps to error cleanup before associating the incoming CEP with it. The cleanup tests whether qp->cep is non-NULL and assumes the current call installed the association. However, qp->cep can point to the CEP of an existing connection. The cleanup then drops a reference from the incoming cep, not qp->cep. Once the incoming endpoint loses its remaining references, this can free it before the subsequent cep->qp store, causing a use-after-free. It also clears the existing QP association. Only release the association reference when qp->cep is the incoming CEP. This preserves an existing association and avoids accessing the freed endpoint.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90293", "url": "https://ubuntu.com/security/CVE-2026-90293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: post the full-feature receive buffers after session registration isert_put_login_tx() posts the full-feature receive buffers before __transport_register_session() runs, so an initiator that does not wait for the final Login Response can still have a SCSI command executed against an se_session whose se_tpg is NULL - the same oops as the previous patch, at target_submit+0xbe. Post them from isert_get_rx_pdu(), which the previous patch already uses to send that response, and post them before that send: the receive queue is filled at the moment the initiator is told it may use it. Allocating there keeps the existing property that a memory allocation failure cannot happen once the final Login Response is on the wire. The receive queue is already empty between the final Login Request and isert_post_recvm(); this moves the second point later, from a median of 92 us to 172 us over 1200 logins. Only an initiator that sends before it has been told to can reach that window, and on IB and RoCE its send is retried there until the buffers appear - isert_rdma_accept() asks for rnr_retry_count = 7. iWARP has no RNR flow control, so there the same send terminates the connection instead. Measured over rxe, 400 login cycles per run, with an initiator that does not wait: an instrumented build counted no entries to isert_recv_done() before the buffers are posted in 10 runs, where that initiator oopsed 8 of 10 unpatched runs and 5 of 10 with only the previous patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90294", "url": "https://ubuntu.com/security/CVE-2026-90294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: delay the final Login Response until the session is registered isert_put_login_tx() puts the final Login Response on the wire before __transport_register_session(), which iscsi_post_login_handler() reaches only after iscsi_target_do_login() returns. An initiator that issues a SCSI command as soon as it sees that response can have it executed against an se_session whose se_tpg is still NULL, and the ib-comp-wq worker oopses on the NULL dereference. Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 0 UID: 0 PID: 178 Comm: kworker/0:1H Not tainted 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT(lazy) 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 Workqueue: ib-comp-wq ib_cq_poll_work RIP: 0010:target_submit+0xbe/0x390 Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP: 0018:ffff8881058cfa78 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88810c78c6f0 RCX: ffffffff964bb363 RDX: 000000000000000f RSI: 00000000fffffe00 RDI: 0000000000000078 RBP: 1ffff11020b19f52 R08: 0000000000000001 R09: ffffed1020b19f52 R10: 0000000000000003 R11: ffff88810596c000 R12: 0000000000000000 R13: ffff88810c61b000 R14: ffff88810c6a3400 R15: ffff88810c61b044 FS: 0000000000000000(0000) GS:ffff8881822b2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1f1b83c000 CR3: 000000006fe72001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __pfx__raw_spin_lock_bh+0x10/0x10 ? __pfx_target_submit+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ? __pfx_isert_recv_done+0x10/0x10 ? rxe_poll_cq+0x253/0x3d0 ? finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: ---[ end trace 0000000000000000 ]--- Delay the final Login Response instead. isert_get_rx_pdu() runs from iscsi_target_rx_thread() after conn->rx_login_comp, completed by iscsi_post_login_handler() after __transport_register_session(); iscsi-TCP and cxgbit already take PDUs from that thread, isert alone does not. The buffers are still posted first, so the initiator's first command does not meet an empty receive queue and nothing depends on RNR flow control, and the header and payload live in isert_conn, not in the struct iscsi_login that iscsi_target_nego_release() frees first. Over rxe, 400 login cycles per run, the oops appeared in 10 of 20 unpatched runs and in none of 20 runs with this patch. An initiator that never waits is handled by the next patch. Not tested: iWARP, discovery sessions over iSER, and real HCAs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90295", "url": "https://ubuntu.com/security/CVE-2026-90295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: \timx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), \t\t\t\t GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90296", "url": "https://ubuntu.com/security/CVE-2026-90296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix devres accumulation across driver rebind imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90297", "url": "https://ubuntu.com/security/CVE-2026-90297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: crtc: Propagate layer initialization error sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90298", "url": "https://ubuntu.com/security/CVE-2026-90298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: tcon: Drop TCON TOP device reference of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90302", "url": "https://ubuntu.com/security/CVE-2026-90302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: synchronize heartbeat callbacks with o2net teardown Patch series \"ocfs2: harden heartbeat teardown races\". This series fixes two OCFS2 heartbeat/o2net teardown races found by KASAN. This patch (of 2): Heartbeat callbacks stay registered while configfs local-node teardown enters o2net_stop_listening(). A node-down event can still run through o2net_disconnect_node() and o2net_set_nn_state() while teardown is destroying o2net_wq, so the later queue/flush operations can hit a dead workqueue. KASAN has caught this as a slab-use-after-free in __queue_work() with the call chain: KASAN slab-use-after-free in __queue_work+0x56/0xa90 Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __queue_work+0x56/0xa90 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 __queue_delayed_work+0x58/0x1e0 queue_delayed_work_on+0xb4/0xc0 o2net_set_nn_state+0x467/0x840 o2net_disconnect_node+0x7b/0xe0 o2net_hb_node_down_cb+0x54/0x60 o2hb_run_event_list+0x236/0x2d0 o2hb_check_slot+0xad4/0xbc0 lock_release+0xc8/0x290 o2hb_check_slot+0x9ea/0xbc0 trace_hardirqs_on+0x18/0x130 o2hb_do_disk_heartbeat+0x646/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) __lock_acquire+0x466/0x2260 lockdep_hardirqs_on_prepare+0xea/0x1a0 ktime_get_with_offset+0xe9/0x230 o2hb_thread+0x14e/0x770 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 __switch_to+0x2e9/0x730 ret_from_fork_asm+0x1a/0x30 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x292/0x760 __alloc_workqueue+0x736/0xc60 alloc_workqueue_noprof+0xb1/0x110 o2net_start_listening+0xe5/0x430 o2nm_node_local_store+0x184/0x310 configfs_write_iter+0x18a/0x210 vfs_write+0x469/0x810 ksys_write+0xd2/0x170 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 rcu_core+0x4f4/0x1320 handle_softirqs+0x156/0x660 queue_delayed_work_on o2net_set_nn_state o2net_disconnect_node o2net_hb_node_down_cb o2hb_run_event_list Keep heartbeat callbacks registered so quorum state still tracks node state, but stop them from driving o2net reconnect/disconnect work once local teardown starts. Mark the transport offline before destroying o2net_wq, wait for any in-flight heartbeat callback to finish, and delay bring-up replay until the new local node is published through o2nm_this_node(). The replay also has to stay serialized with heartbeat callback delivery. Otherwise a live-node snapshot can be copied, a real hb_down callback can install -ENOTCONN for a peer, and the stale replay can call o2net_hb_node_up() for that same peer and queue reconnect work even though heartbeat is already down. The buggy scenario involves two paths, with each column showing the order within that path: local-node teardown: heartbeat node-down callback: 1. configfs local-off enters 1. o2hb_run_event_list() invokes o2net_stop_listening(). o2net_hb_node_down_cb(). 2. teardown heads for 2. the callback reaches destroy_workqueue(o2net_wq). o2net_disconnect_node() and o2net_set_nn_state(). 3. teardown destroys and NULLs 3. the callback flushes or queues o2net_wq. work through o2net_wq.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90303", "url": "https://ubuntu.com/security/CVE-2026-90303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faults When CONFIG_DEBUG_USER=y, and cmdline \"user_debug=31\" is set, a user fault may trigger show_pte() without any lock. If another thread in the same process concurrently calls munmap(), the page table pages may be freed while show_pte() is still traversing them, causing a use-after-free in show_pte(). If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table of PMD are freed when show_pte() is running. Acquire mmap_write_lock() around show_pte() for user faults to fix the contention. For user faults, additionally restrict that show_pte() is called only when the addr is a user-space address (addr < TASK_SIZE). This is because the lock of tsk->mm only protects the virtual memory of user address space, furthermore, dumping the page tables of a kernel-space address for user faults is unnecessary and may have security implications. Keep everything unchanged for kernel faults, because the kernel is already in the \"oops\" state, acquiring a lock may risk a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90307", "url": "https://ubuntu.com/security/CVE-2026-90307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes nothing to srp_process_cred_req() and srp_process_aer_req(), which read fixed-size fields from the receive buffer without checking that those fields were received. The buffer size is max_ti_iu_len, which comes from the login response and is not validated. A target that advertises 8 and then sends an 8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent back, so those bytes reach the target. SRP_AER_REQ behaves the same way and also reads req->lun. The leak is 8 bytes per response. max_ti_iu_len also decides which slab cache the buffer comes from. With 8 the buffer is a kmalloc-8 object and the read is entirely outside it: BUG: KASAN: slab-out-of-bounds in srp_recv_done+0x172b/0x1aa0 Read of size 8 at addr ffff888104714da8 by task kworker/u8:3/50 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888104714da0, ffff888104714da8) Without KASAN the returned bytes are whatever is next in the slab. One run returned \".strtab\". rsp->data[3] in srp_process_rsp() has the same problem: only resp_data_len is checked before it is read. Drop a request that is shorter than the structure being parsed, and check byte_len before the tsk_mgmt read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90308", "url": "https://ubuntu.com/security/CVE-2026-90308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold QP references for AE and CM processing AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90309", "url": "https://ubuntu.com/security/CVE-2026-90309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Hold CQ references when processing EQ events EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or error callbacks outside the xarray lock. erdma_destroy_cq() can erase the CQ from the xarray and free its queue buffer and doorbell record while a previously scheduled EQ handler is still using the CQ. Add a CQ refcount and take a reference under the xarray lock with refcount_inc_not_zero(). Remove the CQ from the xarray before dropping the destroy-path reference, then wait for in-flight EQ users before releasing CQ resources.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90313", "url": "https://ubuntu.com/security/CVE-2026-90313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed A potential invalid storage access issue can occur after replacing a cgroup bpf prog. This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90314", "url": "https://ubuntu.com/security/CVE-2026-90314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression \"table_sz - offset - sizeof(*hdr)\", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90316", "url": "https://ubuntu.com/security/CVE-2026-90316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90318", "url": "https://ubuntu.com/security/CVE-2026-90318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fat: release buffer head after rebuilding parent fat_scan_logstart() leaves the matching directory entry's buffer head in sinfo.bh for the caller to release, just like fat_scan(). fat_rebuild_parent() uses the directory entry to rebuild the parent inode for the nostale_ro NFS export path, but does not release sinfo.bh after a successful scan. Release it once fat_build_inode() has consumed the directory entry data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90319", "url": "https://ubuntu.com/security/CVE-2026-90319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90322", "url": "https://ubuntu.com/security/CVE-2026-90322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90325", "url": "https://ubuntu.com/security/CVE-2026-90325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: skip dying blkg in blkcg_activate_policy() When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90327", "url": "https://ubuntu.com/security/CVE-2026-90327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: do not write beyond optlen in getsockopt pep_getsockopt() clamps the reported length to the caller's buffer with min_t(), but then stores the value with put_user(val, (int __user *) optval), which always writes sizeof(int) bytes. A getsockopt() call with an optlen smaller than sizeof(int) thus reports the clamped length yet writes a full int, one to three bytes past the user buffer. Write the value with copy_to_user() bounded by len, so at most optlen bytes are copied, matching the length reported back to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90329", "url": "https://ubuntu.com/security/CVE-2026-90329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: synchronize input before cleaning up a failed probe hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90334", "url": "https://ubuntu.com/security/CVE-2026-90334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: clear cdev pointer after cdev_add() failure tty_cdev_add() drops the cdev reference when cdev_add() fails, but leaves driver->cdevs[index] pointing to freed memory. tty_unregister_device() later passes that stale pointer to cdev_del(), causing a use-after-free. Clear the slot after dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90341", "url": "https://ubuntu.com/security/CVE-2026-90341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: coreboot: Validate table bounds The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90348", "url": "https://ubuntu.com/security/CVE-2026-90348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90352", "url": "https://ubuntu.com/security/CVE-2026-90352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: release hif2 reference on probe IRQ failure The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90353", "url": "https://ubuntu.com/security/CVE-2026-90353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix ext PHY use-after-free on register error path After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90354", "url": "https://ubuntu.com/security/CVE-2026-90354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix double hif2 init on the non-WED path mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90357", "url": "https://ubuntu.com/security/CVE-2026-90357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement The flow is added to dev->twt_list before sending the agreement to the firmware, but the error path leaves it linked while flowid_mask is never set. The flow slot can then be reused and memset while still on the list, corrupting twt_list, and station removal leaves a dangling entry behind that mt7915_mac_twt_sched_list_add() later walks.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90358", "url": "https://ubuntu.com/security/CVE-2026-90358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, x86: Fix trampoline stack size for 128-bit arguments btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots. Compute the register count from arg_size for all arguments to fix it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90360", "url": "https://ubuntu.com/security/CVE-2026-90360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90361", "url": "https://ubuntu.com/security/CVE-2026-90361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix leak in ath11k_service_ready_ext_event() Currently, during ath11k_service_ready_ext_event() processing, svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a temporary allocation that is freed on the success path, but not on the error path. If parsing succeeds far enough to allocate mac_phy_caps and then fails on a later TLV, the allocation leaks. So free the allocation on the error path. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90362", "url": "https://ubuntu.com/security/CVE-2026-90362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Drop dev_pm_opp_set_rate(0) dev_pm_opp_set_rate(0) removes the vote specified in required-opps but does not actually park the clock, making it run without the necessary power backing. Drop the explicit call to it. Every call site of ops->link_clk_disable() is followed by pm_runtime_put(), so the power vote will be rescinded if deemed safe. Patchwork: https://patchwork.freedesktop.org/patch/742783/", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90364", "url": "https://ubuntu.com/security/CVE-2026-90364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Unregister cpufreq notifier on init failure acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90366", "url": "https://ubuntu.com/security/CVE-2026-90366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a near-maximum beacon template the extra 8 bytes could push the offload command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic(). Reserve room for both countdown TLVs.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90368", "url": "https://ubuntu.com/security/CVE-2026-90368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: unwind state on add_interface failure When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90370", "url": "https://ubuntu.com/security/CVE-2026-90370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90372", "url": "https://ubuntu.com/security/CVE-2026-90372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss If a peer's VHT/HE MCS map has no supported spatial stream (all fields 0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255), which was then written into the firmware sta_rec_bf beamforming fields. Clamp the result to 0.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90374", "url": "https://ubuntu.com/security/CVE-2026-90374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[] band_idx comes from a 2-bit descriptor field (0-3) and was used directly to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the result. A corrupt or reserved descriptor value could index out of bounds or hit a NULL phy on parts with fewer bands. Reject invalid band indices, mirroring mt7996_rx_get_wcid().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90375", "url": "https://ubuntu.com/security/CVE-2026-90375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix non-AQL packet accounting for MLO stations __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station. Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90378", "url": "https://ubuntu.com/security/CVE-2026-90378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt792x: Fix memory leak in SDIO TX path When tx_prepare_skb() returns an error in the SDIO TX path, the skb is not freed, leading to a memory leak. This can occur when zero-length frames (such as WNM NULL frames) are dropped to prevent potential hardware TX hangs. Fix this by properly releasing the skb with ieee80211_tx_status_ext() when tx_prepare_skb() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90382", "url": "https://ubuntu.com/security/CVE-2026-90382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length The MPDU length in the rx descriptor comes from the hardware. In monitor mode with the fcsfail filter enabled, the hardware passes up corrupted frames, and a corrupted frame can report a length larger than the received buffer. The bounds check correctly discards such frames, but its WARN_ON_ONCE wrapper means any over-the-air garbage frame taints the kernel, and panics it on the first such frame when panic_on_warn is set. Drop the WARN and discard the frame silently, matching what commit c2d4c8723dbf (\"mt76x2: remove some harmless WARN_ONs in tx status and rx path\") did for the neighboring rx and tx status paths. Observed immediately on rx with an MT7612U in fcsfail monitor mode on a busy channel.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90383", "url": "https://ubuntu.com/security/CVE-2026-90383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: sgi-gru: remove interrupt-context page-table walks The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64. Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context. Remove the mmap-lock failure statistic that can no longer be incremented.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90385", "url": "https://ubuntu.com/security/CVE-2026-90385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1: create serial pool adding rdev to array with serialize_policy=1 The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90386", "url": "https://ubuntu.com/security/CVE-2026-90386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90387", "url": "https://ubuntu.com/security/CVE-2026-90387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90388", "url": "https://ubuntu.com/security/CVE-2026-90388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Check atomic pool allocation result directly The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(), which returns the allocated page and fills cpu_addr only on success. Do not rely on cpu_addr to detect allocation failure in this path. Check the returned page directly before using it for the IOMMU mapping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90389", "url": "https://ubuntu.com/security/CVE-2026-90389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: scope memalloc_noio to allocation critical sections Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90390", "url": "https://ubuntu.com/security/CVE-2026-90390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/bitmap: resume array on backlog_store() error path backlog_store() suspends the array before checking whether a write-mostly device exists. If no such device exists, the error path only unlocks reconfig_mutex and leaves the array suspended, blocking subsequent I/O. Use mddev_unlock_and_resume() to release both states.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90391", "url": "https://ubuntu.com/security/CVE-2026-90391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90392", "url": "https://ubuntu.com/security/CVE-2026-90392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90393", "url": "https://ubuntu.com/security/CVE-2026-90393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF in bpf_netns_link_update_prog In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90394", "url": "https://ubuntu.com/security/CVE-2026-90394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: sc2731_charger: cancel work on remove The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released. Set the platform drvdata used by remove, then cancel the work after unregistering the notifier. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90395", "url": "https://ubuntu.com/security/CVE-2026-90395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: isp1704_charger: cancel work on remove The USB notifier and initial VBUS detection can schedule isp->work. The remove path unregisters the notifier and power supply, but does not wait for queued or running work before tearing down the power supply state. Cancel the work after unregistering the notifier. Do this before unregistering the power supply. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90397", "url": "https://ubuntu.com/security/CVE-2026-90397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90398", "url": "https://ubuntu.com/security/CVE-2026-90398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90399", "url": "https://ubuntu.com/security/CVE-2026-90399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix stride mismatch in mac_phy_caps_parse() Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90400", "url": "https://ubuntu.com/security/CVE-2026-90400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90403", "url": "https://ubuntu.com/security/CVE-2026-90403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix error path in rtl_pci_probe() In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90404", "url": "https://ubuntu.com/security/CVE-2026-90404", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_debugfs: Unregister panic notifier cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90407", "url": "https://ubuntu.com/security/CVE-2026-90407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event() There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read. Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90410", "url": "https://ubuntu.com/security/CVE-2026-90410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: davinci: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory. Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90411", "url": "https://ubuntu.com/security/CVE-2026-90411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request __nvme_fc_init_request() maps cmd_iu and then rsp_iu for DMA. If the rsp_iu mapping fails, the original code only recorded the error and fell through: it left the already-mapped cmd_iu unmapped and still marked the op as FCPOP_STATE_IDLE before returning. Since blk-mq does not call .exit_request() when .init_request() fails, the cmd_iu mapping is leaked for every op whose rsp_iu mapping fails. Jump to an error path on rsp_iu mapping failure that unmaps cmd_iu and returns the error without marking the op idle, so it stays in the FCPOP_STATE_UNINIT state set by the initial memset().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90413", "url": "https://ubuntu.com/security/CVE-2026-90413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject login PDUs declaring more data than was received isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(), \tpayload_length = ntoh24(login_req->dlength); \ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL); and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login(). login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region Falsifying the second login PDU instead reaches the other reader, on the same buffer: BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0 iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all. Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding. Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len. Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away. Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90414", "url": "https://ubuntu.com/security/CVE-2026-90414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: reject PDUs declaring more data than was received isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor: isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len); Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer. Nothing upstream of isert closes this door: - __iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated. The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated. Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN: BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode(). Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\"IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN\")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all. isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90415", "url": "https://ubuntu.com/security/CVE-2026-90415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: free STAG index when TPT entry write fails write_tpt_entry() allocates a new STAG index with c4iw_get_resource() and bumps stats.stag.cur before programming the entry. When write_adapter_mem() fails, it returns the error without releasing the index or reversing the statistic. No MR is inserted into rhp->mrs, so deregistration never reclaims it, leaking the index until device teardown. Record whether this call allocated the index and, on a failed write, return it to tpt_table and decrement stats.stag.cur. Key the rollback on both the write error and that flag, not the error alone: a non-reset update carries a caller-owned STAG that this call did not allocate and must not free.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90416", "url": "https://ubuntu.com/security/CVE-2026-90416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed \"%d\" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as \"-2147483648\\n\" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with \"%u\" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90418", "url": "https://ubuntu.com/security/CVE-2026-90418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache. The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status. This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode. Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode. Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90419", "url": "https://ubuntu.com/security/CVE-2026-90419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90420", "url": "https://ubuntu.com/security/CVE-2026-90420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix infinite loop in nilfs_clean_segments() syzbot reported a hung task in nilfs_transaction_begin(). This occurs because the cleaner ioctl falls into an infinite loop if nilfs_segctor_construct() repeatedly returns -EROFS (e.g. the device is remounted as read-only after an I/O error). Currently in nilfs_clean_segments(), if err is non-zero, it logs the error and sleeps but doesn't abort when it encounters a terminal error like -EROFS. This causes the thread to loop forever. Fix this by breaking out of the loop if nilfs_segctor_construct() returns -EROFS. This matches the behaviour in nilfs_segctor_write_out(), which also handles -EROFS.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89782", "url": "https://ubuntu.com/security/CVE-2026-89782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: reject restart table growth beyond U16_MAX entries During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index. alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl(): \trt = init_rsttbl(esize, used + add); used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image. BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-90431", "url": "https://ubuntu.com/security/CVE-2026-90431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: Prevent crash handling to race with rproc_del() There's no synchronization between rproc_crash_handler_work() and rproc_del(), as such it's possible for a driver to be removed while crash-handler work is scheduled, or even executing - resulting in use-after-free issues. To avoid this the scheduled work need to be cancelled and synchronized against before the removal proceeds. In order to ensure that this doesn't race with the reporting, and thereby scheduling new work, a \"deleting\" flag is introduced. This is similar to the RPROC_DELETE state that was introduced to ensure that \"start\" didn't race with rproc_del(), but the existing mechanism can not be used as it's valid to call rproc_report_crash() in atomic context - and the \"state\" is protected by a mutex. In the event that work is cancelled the pm_stay_awake() is left unbalanced and need to be unrolled. The blocking and cancelling of crash-handler work prior to the actual rproc_shutdown() call does have the explicit side-effect that crashes resulting from the shutdown process will not enter the crash-handling path, and as such will not generate devcoredumps etc. Due to the existing mutual exclusion between these code paths there's no concrete reduction in functionality, but further work would be needed to handle this case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90433", "url": "https://ubuntu.com/security/CVE-2026-90433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: oc-tiny: switch to managed controller allocation The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90434", "url": "https://ubuntu.com/security/CVE-2026-90434", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: release zisofs block pointer buffer head zisofs_fill_pages() reads the compressed block pointer table. The error paths release the current buffer_head, the loop also releases the old buffer_head when it advances. However, the success path leaves the last buffer_head referenced. Release it before returning success.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-90435", "url": "https://ubuntu.com/security/CVE-2026-90435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix integer overflow of user QP buffer size set_user_buf_size() computes the QP buffer size by left-shifting the user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers. A sufficiently large rq.wqe_cnt causes signed integer overflow, which is undefined behavior, and yields a small or negative buf_size, causing ib_umem_get() to map a buffer smaller than the hardware will actually write into. Replace the shifts and addition with check_shl_overflow() and check_add_overflow(), rejecting invalid user inputs. Moreover, guard the identical shift computing qp->sq.offset in _create_user_qp() before set_user_buf_size() is reached.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92476", "url": "https://ubuntu.com/security/CVE-2026-92476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Initialize completion before requesting IRQ kmb_ocs_aes_probe() requests the device IRQ before initializing irq_completion. Once the handler is registered it can run immediately, and ocs_aes_irq_handler() unconditionally calls complete(). An interrupt in this window would therefore use an uninitialized completion. Initialize the completion before requesting the IRQ, as the sibling OCS HCU and ECC drivers already do.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92477", "url": "https://ubuntu.com/security/CVE-2026-92477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: debugfs: Reserve space for a string terminator ufs_saved_err_write() copies user input into a zero-initialized stack buffer and passes it to kstrtoint(). A write that fills the entire buffer overwrites its only terminator. Reject an input whose length leaves no room for the trailing NUL.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92481", "url": "https://ubuntu.com/security/CVE-2026-92481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data. The plain allocations in mtk_eint_do_init() already use the device-managed devm_*() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92484", "url": "https://ubuntu.com/security/CVE-2026-92484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix use-after-free in find_pos_and_ways() error path The error path releases its reference to a switch decoder before logging an error that includes the decoder name. If the released reference is the last one, the decoder can be freed before the error message accesses its name. Drop the reference after the error is reported.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89785", "url": "https://ubuntu.com/security/CVE-2026-89785", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92488", "url": "https://ubuntu.com/security/CVE-2026-92488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: complete object teardown when the destroy command fails erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92489", "url": "https://ubuntu.com/security/CVE-2026-92489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix skb double-free in xfrm_dev_direct_output() A return value other than 1 from local_out() means that the skb has been consumed or its ownership was transferred. xfrm_dev_direct_output() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner. Return the local_out() result directly, matching the ownership handling in xfrm_output_resume().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92490", "url": "https://ubuntu.com/security/CVE-2026-92490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unrequest devices if driver registration fails scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89787", "url": "https://ubuntu.com/security/CVE-2026-89787", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check dir entry fits before reading the hash trailer in ext4_search_dir() For casefolded encrypted directories ext4 stores an 8-byte hash trailer after the name (EXT4_DIRENT_HASHES()), at an offset derived from de->name_len. On the sb_no_casefold_compat_fallback() path ext4_match() reads that trailer, but ext4_search_dir()'s by-hand pre-check only tests de->name + de->name_len <= dlimit, which proves the name fits, not the rounded trailer. A crafted entry whose name ends at the block boundary passes the check while EXT4_DIRENT_HASHES(de) lands past the block end, so ext4_match() reads out of bounds on an ordinary lookup. KASAN reports it as a use-after-free when the page after the directory block holds a freed object: BUG: KASAN: use-after-free in ext4_match (fs/ext4/namei.c:1435) Read of size 4 at addr ffff888010458000 by task exploit Call Trace: ext4_match (fs/ext4/namei.c:1435) ext4_search_dir (fs/ext4/namei.c:1470) __ext4_find_entry (fs/ext4/namei.c:1268 fs/ext4/namei.c:1632) ext4_lookup (fs/ext4/namei.c:1703 fs/ext4/namei.c:1769) ... filename_lookup (fs/namei.c:2842) vfs_statx (fs/stat.c:353) __do_sys_newfstatat (fs/stat.c:538) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Require, for hash-in-dirent directories, that the whole entry including the rounded trailer fits before calling ext4_match(). This is the same bound ext4_check_dir_entry() already enforces via ext4_dir_rec_len(), so no well-formed entry is rejected. The other caller, ext4_find_dest_de(), runs ext4_check_dir_entry() first and is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92494", "url": "https://ubuntu.com/security/CVE-2026-92494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix buffer_head leak in ext4_init_orphan_info ext4_init_orphan_info() reads orphan file blocks with ext4_bread() and stores the returned buffer_head in oi->of_binfo[i].ob_bh. If ext4_bread() succeeds but the orphan block magic or checksum validation fails, the function jumps to out_free. However, the old out_free loop starts releasing buffers from i - 1, so the current buffer_head at index i is skipped. This leaks the buffer_head reference obtained by ext4_bread() on the bad magic and bad checksum error paths. Fix this by tracking the number of successfully read buffer_heads and releasing exactly those buffer_heads on the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92495", "url": "https://ubuntu.com/security/CVE-2026-92495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap bnxt_re_mmap() rejects VM_WRITE for the DBR_PAGE and TOGGLE_PAGE mmap flags, but a read-only mapping can still retain VM_MAYWRITE. nd later be upgraded with mprotect(PROT_WRITE). This can bypass the write check that only runs at mmap time. Clear VM_MAYWRITE before vm_insert_page() in the shared DBR/toggle-page branch, matching the existing policy that userspace writes are not expected for these pages.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92496", "url": "https://ubuntu.com/security/CVE-2026-92496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx() Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Add an upfront length check before dereferencing skb->data as a wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event() call to preserve the existing trace semantics (tracing the full raw WMI event including the header), unlike the analogous ath12k fix which could use skb_pull_data() directly. Compile tested only.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92497", "url": "https://ubuntu.com/security/CVE-2026-92497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx() Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without first verifying that the buffer has enough data to hold a header. This could result in a buffer overread. Update the logic to verify the buffer contains at least enough data to hold a wmi_cmd_hdr before reading from the buffer. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92498", "url": "https://ubuntu.com/security/CVE-2026-92498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: avoid buffer overreads in WMI event handlers The following WMI event handlers currently read from the event buffer without first verifying that the message was large enough to hold the expected event: ath6kl_wmi_scan_complete_rx() ath6kl_wmi_addba_req_event_rx() ath6kl_wmi_delba_req_event_rx() Add length checks to prevent overread.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92501", "url": "https://ubuntu.com/security/CVE-2026-92501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drain in-flight DIO before buffered write fallback generic/746 started failing intermittently on ext3 (no-extent inodes). The test triggers 'Page cache invalidation failure on direct I/O' warnings and subsequent fsync returns -EIO. Adding a 50ms delay between ext4_buffered_write_iter() and filemap_write_and_wait_range() in ext4_dio_write_iter() makes the race almost always reproducible. On no-extent inodes, DIO writes to holes cannot use unwritten extents, so ext4_iomap_alloc() leaves m_flags=0 and ext4_map_blocks() returns 0. The iomap layer then returns -ENOTBLK, causing fallback to buffered I/O. The fallback path in ext4_dio_write_iter() calls ext4_buffered_write_iter() which dirties pages, then does flush and invalidate. However, there's an unprotected window between ext4_buffered_write_iter() returning (with inode lock released) and the subsequent flush+invalidate. Concurrent async DIO completions from other threads can run kiocb_invalidate_post_direct_write() during this window. If pages have been re-dirtied, post-invalidation finds dirty pages and triggers the warning, setting -EIO in the error sequence. Consider a file with two 4k extents: [hole][written]. Thread A does DIO to the written extent, while thread B does DIO spanning both: kworker A (4k DIO, allocated block) kworker B (8k DIO, fallback) ----------------------------------- ---------------------------- inode_lock_shared() inode_lock_shared() iomap_dio_rw(): iomap_dio_rw(): kiocb_invalidate_pages -> clean iomap_begin -> -ENOTBLK submit_bio (async) dio->size = 0 inode_unlock_shared() inode_unlock_shared() [bio pending in block layer] /* fallback: lock released */ ext4_buffered_write_iter() inode_lock(exclusive) generic_perform_write() -> dirty pages [0, 8k] inode_unlock(exclusive) /* pages dirty, no lock */ [bio completes] filemap_write_and_wait_range() iomap_dio_complete() -> flush dirty pages kiocb_invalidate_post_direct_write() invalidate_mapping_pages() invalidate_inode_pages2_range() -> finds dirty page! -> dio_warn_stale_pagecache() -> errseq_set(-EIO) This issue can be triggered through normal I/O paths, not just intentionally overlapping DIO writes from userspace. For example, generic/746 uses a loop device where multiple kworkers issue concurrent I/O to the backing file. Additionally, when block_size < folio_size, non-overlapping DIO writes that share a large folio can also trigger the race. Add inode_dio_wait() in ext4_buffered_write_iter() before ext4_write_checks() to drain all in-flight DIO. This ensures that all DIO clears existing pages before submitting IO (via kiocb_invalidate_pages()), all BIO waits for all DIO to complete (via inode_dio_wait()), and ext4_write_checks() observes the inode size after all completed DIO so that ext4_block_zero_eof() does not race with in-flight DIO, thus eliminating the race.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92504", "url": "https://ubuntu.com/security/CVE-2026-92504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int3400: clean up ODVP on probe failures evaluate_odvp() creates per-ODVP sysfs files before the thermal zone and later probe resources are registered. The current unwind path only calls cleanup_odvp() from the late sysfs failure path, so failures after evaluate_odvp() but before that label, including thermal_tripless_zone_device_register() failures, leave the ODVP files and storage behind. Move the ODVP cleanup to the common ART/TRT unwind path so every failure after evaluate_odvp() releases the ODVP state. Also clear the cached ODVP pointers in cleanup_odvp(), because evaluate_odvp() can already call it for partial setup failures while probe continues.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92506", "url": "https://ubuntu.com/security/CVE-2026-92506", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92507", "url": "https://ubuntu.com/security/CVE-2026-92507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_dealloc_pd_user() When accessing a PD via the netlink path the only synchronization mechanism for the said PD is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_dealloc_pd_user(), which is too late, since by that point vendor-specific resources associated with the PD might already be freed. This can leave a short window where the PD remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_dealloc_pd_user(), ensuring that the PD is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a PD that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92508", "url": "https://ubuntu.com/security/CVE-2026-92508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_free_cq() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_free_cq(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92509", "url": "https://ubuntu.com/security/CVE-2026-92509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in counter_release() When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92510", "url": "https://ubuntu.com/security/CVE-2026-92510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_srq_user() When accessing a SRQ via the netlink path the only synchronization mechanism for the said SRQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_srq_user(), which is too late, since by that point vendor-specific resources associated with the SRQ might already be freed. This can leave a short window where the SRQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_srq_user(), ensuring that the SRQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a SRQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92511", "url": "https://ubuntu.com/security/CVE-2026-92511", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in ib_destroy_cq_user() When accessing a CQ via the netlink path the only synchronization mechanism for the said CQ is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of ib_destroy_cq_user(), which is too late, since by that point vendor-specific resources associated with the CQ might already be freed. This can leave a short window where the CQ remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_begin_del() call to the start of ib_destroy_cq_user(), ensuring that the CQ is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a CQ that is in the process of destruction. In addition, this change preserves the intended inverted order between create and destroy routines: resources are added to restrack at the end of successful creation, and hence shall be removed from the restrack first thing during the destruction flow, which keeps the lifecycle management consistent and predictable.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92512", "url": "https://ubuntu.com/security/CVE-2026-92512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "high", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-74334", "url": "https://ubuntu.com/security/CVE-2026-74334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Fix locking when accessing mr->pd Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-92514", "url": "https://ubuntu.com/security/CVE-2026-92514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Fix CEQ tasklet use-after-free on removal Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92519", "url": "https://ubuntu.com/security/CVE-2026-92519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix memory leak in bpf_jit_free When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89786", "url": "https://ubuntu.com/security/CVE-2026-89786", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bounds read in ext4_read_inline_dir() ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64(): BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir The dirent payload lives in a buffer of exactly inline_size bytes: \tdir_buf = kmalloc(inline_size, GFP_NOFS); but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic \".\" and \"..\" land at their block-dir offsets. A dirent is formed at \"dir_buf + pos - extra_offset\", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected. Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-92521", "url": "https://ubuntu.com/security/CVE-2026-92521", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92522", "url": "https://ubuntu.com/security/CVE-2026-92522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: validate MADT IOAPIC entry bounds The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92523", "url": "https://ubuntu.com/security/CVE-2026-92523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: validate dynamic counter attribute length RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92524", "url": "https://ubuntu.com/security/CVE-2026-92524", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-92525", "url": "https://ubuntu.com/security/CVE-2026-92525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[] For a user QP, qp->sq.queue is a ring the application writes directly, so rxe_post_send() takes the is_user branch and only schedules send_task without validating the WQE. rxe_requester() consumes it in place via req_next_wqe() and calls copy_data(), which indexes &wqe->dma.sge[cur_sge] with the attacker-controlled num_sge/cur_sge. Only the kernel path bounds num_sge (validate_send_wr()); the user WQE is never checked, so a local unprivileged user can post a WQE with an out-of-range cur_sge or oversized num_sge and force an out-of-bounds read of the per-WQE sge array in copy_data() (vmalloc OOB read, local DoS). Bound num_sge to qp->sq.max_sge in rxe_requester() before use, the way get_srq_wqe() already guards SRQ entries, and bound cur_sge only when the WQE carries payload (dma.resid): copy_data() returns early on a zero-length copy before touching dma->sge[], so a zero-payload WQE -- the only kind a max_sge == 0 QP can post -- stays valid. Reproduced under KASAN; the vmalloc-out-of-bounds in copy_data() is gone.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93037", "url": "https://ubuntu.com/security/CVE-2026-93037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Propagate sdma_txinit_ahg() errors set_txreq_header_ahg() ignores the return value of sdma_txinit_ahg(). If sdma_txinit_ahg() fails, it returns before initializing tx->txreq. However, set_txreq_header_ahg() ignores the error and returns the AHG change count, causing the caller to continue processing the request as though initialization had succeeded. Propagate sdma_txinit_ahg() failures to the caller and abort request processing when initialization fails. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93039", "url": "https://ubuntu.com/security/CVE-2026-93039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: Keep link pointers valid on realloc failure meson_card_reallocate_links() grows the DAI link and private data arrays with two consecutive krealloc() calls and updates the owner pointers only after both calls have succeeded. A successful krealloc() may move the data: it frees the old block and returns a new one. When that happens for the link array and the second krealloc() then fails, card->dai_link still points to the block that krealloc() already freed, and the error path frees the new block too. The probe error path then calls meson_card_clean_references(), which dereferences card->dai_link and kfree()s it again, resulting in a use-after-free and a double free. Commit card->dai_link and card->num_links right after the first krealloc() succeeds, so the pointer always refers to a valid allocation that meson_card_clean_references() can walk and free. krealloc() with __GFP_ZERO zero-initializes the added entries, so walking them on the error path is safe. With both failure paths reduced to a plain return, drop the goto labels and the error message.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93040", "url": "https://ubuntu.com/security/CVE-2026-93040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93041", "url": "https://ubuntu.com/security/CVE-2026-93041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize abort state updates dw_edma_abort_interrupt() drops vc.lock before changing request and status. issue_pending() can acquire the lock in that small window, observe the old busy state, and skip starting queued descriptors. Then the abort handler overwrites the channel status as idle, leaving the new descriptors stranded for good. Keep descriptor completion and the state transition in the same critical section.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93042", "url": "https://ubuntu.com/security/CVE-2026-93042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Terminate all descriptors without callbacks The DMA Engine client documentation says in the \"Terminate APIs\" section of Documentation/driver-api/dmaengine/client.rst: \"No callback functions will be called for any incomplete transfers.\" dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak. Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks. A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93046", "url": "https://ubuntu.com/security/CVE-2026-93046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: software node: Fix software_node_get_reference_args() with index -1 The bounds check for the index passed to software_node_get_reference_args() was failing when passed UINT_MAX, this in turn would lead to an out of bound access in the property array. Fix the bound check to also cover the UINT_MAX case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93048", "url": "https://ubuntu.com/security/CVE-2026-93048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd_add_partition() does not reject the special offset value MTDPART_OFS_RETAIN (-3), which leads to a WARN_ON in add_mtd_device() when called through the BLKPG ioctl on NAND devices. The RETAIN value depends on cur_offset being the end of the previous partition, but in the dynamic partition path cur_offset equals the offset argument itself, causing undefined behavior. Commit 5daa7b21496a (\"mtd: prepare partition add and del functions for ioctl requests\") introduced mtd_add_partition() and correctly rejected MTDPART_OFS_APPEND (-1) and MTDPART_OFS_NXTBLK (-2), since those special offsets rely on cur_offset tracking the previous partition's end. However, commit 1a31368bf92e (\"mtd: add a flags for partitions which should just leave smth. after them\") later added MTDPART_OFS_RETAIN (-3) for the static partition table path without updating mtd_add_partition() to also reject this value. With offset=-3 passed via BLKPG, the RETAIN size calculation in allocate_partition() underflows (parent_size - 0xFFFFFFFFFFFFFFFD = parent_size + 3). If the underflow result does not appear to leave enough space, allocate_partition() jumps to out_register via goto, skipping erasesize initialization. This results in erasesize=0, which triggers: WARN_ON((!mtd->erasesize || !master->_erase) && \t\t!(mtd->flags & MTD_NO_ERASE)) in add_mtd_device(). If the underflow result appears to leave enough space, a bogus partition size is calculated, but the \"out of reach\" sanity check catches the invalid offset and creates a disabled empty partition (offset=0, size=0) instead of returning an error. Fix this by adding MTDPART_OFS_RETAIN to the rejection list in mtd_add_partition(), consistent with the existing handling of APPEND and NXTBLK.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93049", "url": "https://ubuntu.com/security/CVE-2026-93049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdswap: Avoid freeing registered blktrans device twice In mtdswap_add_mtd(), debugfs setup failure after successful blktrans registration can free mbd_dev twice. add_mtd_blktrans_dev() initializes the blktrans device reference and publishes the disk. Once that succeeds, del_mtd_blktrans_dev() tears the disk down and drops the blktrans reference; when that reference reaches zero, blktrans_dev_release() frees the mtd_blktrans_dev. The debugfs failure path called del_mtd_blktrans_dev(mbd_dev), then fell through the common cleanup label and called kfree(mbd_dev) again. Clear the local pointer after deregistration so the common cleanup can still release the mtdswap state without freeing the blktrans object twice. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-89777", "url": "https://ubuntu.com/security/CVE-2026-89777", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: clear vdev->msi_perm after freeing it on init failure vfio_msi_cap_len() lazily allocates the per-device MSI permission table: \tvdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); \tif (!vdev->msi_perm) \t\treturn -ENOMEM; \tret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); \tif (ret) { \t\tkfree(vdev->msi_perm); \t\treturn ret;\t\t/* vdev->msi_perm left dangling */ \t} When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at \"if (vdev->msi_perm) return len;\" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93050", "url": "https://ubuntu.com/security/CVE-2026-93050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup on remove Three issues arise when the device is removed while a tty session is still active: 1. UAF of struct ipoctal: the remove callback frees ipoctal via kfree() while tty ops may still access it. Fix by introducing kref-based lifetime management — kref is taken in install() when a tty is opened and released in cleanup() when the tty is finally destroyed; remove() uses kref_put() instead of kfree(). 2. NULL dereference in ipoctal_write_tty(): __ipoctal_remove() frees xmit_buf via tty_port_free_xmit_buf() while a userspace process may still hold the tty fd and call write(). Fix by checking for NULL xmit_buf in ipoctal_write_tty(). 3. UAF in ipoctal_cleanup(): ipack_put_carrier(ipoctal->dev) dereferences ipoctal->dev after the ipack_device has been freed by ipack_device_del(). Fix by caching ipoctal->carrier_owner during probe() and calling module_put() on the cached pointer directly in cleanup(), avoiding any access to ipoctal->dev. Also introduce a \"removed\" flag in struct ipoctal, set at the start of __ipoctal_remove(), and checked in every tty op that accesses hardware resources (port_activate, write_tty, set_termios, hangup, shutdown). This prevents page faults when devm_ioremap() regions are unmapped after remove() returns.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93051", "url": "https://ubuntu.com/security/CVE-2026-93051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ad525x_dpot: use driver core groups for sysfs files ad_dpot_probe() creates per-RDAC sysfs files manually and then optionally creates the command sysfs group. This leaves probe responsible for rolling back partial sysfs state and makes remove responsible for matching every file that probe created. Move the device attributes into driver core dev_groups for the I2C and SPI drivers and use an is_visible() callback to expose only the attributes supported by the probed device. With this shape, the driver core creates the sysfs files only after probe succeeds and removes them before the remove callback frees the driver data.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93052", "url": "https://ubuntu.com/security/CVE-2026-93052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93053", "url": "https://ubuntu.com/security/CVE-2026-93053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: speakup: keyhelp: guard letter_offsets possible out-of-range indexing help_init() builds letter_offsets[] by using the first byte of each function name as an index via `(start & 31) - 1`. If function_names are overridden from sysfs (root) with a name starting outside [a–z], the index underflows or exceeds the array, leading to OOB write. Function names can be overridden with the following commands as root: modprobe speakup_soft echo \"0 _bad\" > /sys/accessibility/speakup/i18n/function_names # then press Insert+2 on /dev/tty This fix checks the first letter in help_init(), and if it is not in the [a–z] range the function returns an error to the caller. Eventually this error is propagated to drivers/accessibility/speakup/main.c:2217, which causes a bleep sound.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93054", "url": "https://ubuntu.com/security/CVE-2026-93054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same \"device gone\" state as normal uio_unregister_device().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93055", "url": "https://ubuntu.com/security/CVE-2026-93055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93056", "url": "https://ubuntu.com/security/CVE-2026-93056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: remove broken string configfs attributes The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for the fn_play, fn_cap, and fn_cntl string options. The store function contains an inverted null check on the kstrndup() return value. This means every write attempt returns -ENOMEM on success and dereferences a NULL pointer on allocation failure. The attributes have been broken and unused for many years. Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE, FILE_CONTROL) set in f_audio_alloc_inst() are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93061", "url": "https://ubuntu.com/security/CVE-2026-93061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Avoid stack over-read in debug output helpers host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit. This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur. Fix by switching to vscnprintf(), which returns the number of bytes actually written.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93062", "url": "https://ubuntu.com/security/CVE-2026-93062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:17:00 UTC" }, { "cve": "CVE-2026-93063", "url": "https://ubuntu.com/security/CVE-2026-93063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: check SAP message length before reading it Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93064", "url": "https://ubuntu.com/security/CVE-2026-93064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser iwl_mvm_frob_txf_key_iter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93065", "url": "https://ubuntu.com/security/CVE-2026-93065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs The loop counter 'count' was declared as u8 while num_pc is u32. If firmware advertises more than 255 PC entries the counter wraps back to zero and the loop never terminates potentially causing an infinite loop or reading past the allocated pc_data array. Change the declaration to u32 to match num_pc.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93067", "url": "https://ubuntu.com/security/CVE-2026-93067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: clamp the reported AUX read size to the request tc_aux_transfer() clamps an AUX read to the payload limit: \tsize_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); After the transfer it replaces size with the byte count the controller reports in AUX_BYTES: \tif (size) \t\tsize = FIELD_GET(AUX_BYTES, auxstatus); AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both. The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 (\"drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer\").", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93072", "url": "https://ubuntu.com/security/CVE-2026-93072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/renesas-irqc: Fix generic interrupt chip leak on remove The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93073", "url": "https://ubuntu.com/security/CVE-2026-93073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax: read holder_ops once in dax_holder_notify_failure() dax_holder_notify_failure() reads dax_dev->holder_ops twice without READ_ONCE() -- once for the NULL check and once for the indirect notify_failure() call. A concurrent fs_put_dax() can clear holder_ops between the two reads, so the check can observe a non-NULL pointer while the call dereferences NULL. (kill_dax() also clears holder_ops, but only after synchronize_srcu(), so it cannot race a reader that is inside dax_read_lock(); fs_put_dax() does no such synchronization.) Fetch holder_ops once into a local with READ_ONCE() so the NULL check and the indirect call observe the same value.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93083", "url": "https://ubuntu.com/security/CVE-2026-93083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unwind TX receiver mailbox setup failure mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93084", "url": "https://ubuntu.com/security/CVE-2026-93084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Drop handle on protocol bind failures The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93085", "url": "https://ubuntu.com/security/CVE-2026-93085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Reject out of range DT protocol IDs SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93086", "url": "https://ubuntu.com/security/CVE-2026-93086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Avoid IDR updates while cleaning channels scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93089", "url": "https://ubuntu.com/security/CVE-2026-93089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Free transport channel on IDR failure If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93090", "url": "https://ubuntu.com/security/CVE-2026-93090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Clean up channels on setup failure scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93092", "url": "https://ubuntu.com/security/CVE-2026-93092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Unregister device notifier before IDR teardown The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93093", "url": "https://ubuntu.com/security/CVE-2026-93093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Publish channel state before callbacks Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93095", "url": "https://ubuntu.com/security/CVE-2026-93095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: validate thread record before delete key rebuild hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName. That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name. A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation. Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name. Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-90048", "url": "https://ubuntu.com/security/CVE-2026-90048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list() ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop. A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer. This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(). BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 ni_create_attr_list+0xc48/0x1058 ni_ins_attr_ext+0x510/0x7c0 ni_insert_attr+0x3f8/0x70c ni_insert_resident+0xc8/0x3b0 ntfs_set_ea+0x66c/0xd28 ntfs_setxattr+0x4d8/0x5b0 __arm64_sys_setxattr+0xa4/0x124 Allocated by task 345: ni_create_attr_list+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024). Size the buffer from the actual attributes instead of assuming a single record_size is always enough.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2024-52560", "url": "https://ubuntu.com/security/CVE-2024-52560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr() Extended the `mi_enum_attr()` function interface with an additional parameter, `struct ntfs_inode *ni`, to allow marking the inode as bad as soon as an error is detected.", "cve_priority": "high", "cve_public_date": "2025-02-27 03:15:00 UTC" }, { "cve": "CVE-2026-93097", "url": "https://ubuntu.com/security/CVE-2026-93097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Break poison list loop on an empty payload A device that returns count == 0 with CXL_POISON_FLAG_MORE set on every iteration never advances nr_records, so the max_errors guard never trips and the do/while loops forever while holding poison.mutex. That hangs the sysfs-triggered scan thread and blocks all subsequent poison operations on the device. The existing \"Protect against an uncleared _FLAG_MORE\" guard was intended to bound a misbehaving device but does not cover the count == 0 case. Stop the loop on an empty payload so a malfunctioning or malicious device cannot wedge the poison scan.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93098", "url": "https://ubuntu.com/security/CVE-2026-93098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: glink: fix deadlock in endpoint destroy during driver detach During driver detach, the device core holds the device mutex throughout the driver's remove callback chain. When the rpmsg endpoint is destroyed as part of that teardown, the GLINK endpoint destroy implementation attempts to unregister the underlying rpmsg device. That unregistration calls device_del(), which tries to re-acquire the same device mutex already held higher up the stack, causing rmmod to hang indefinitely. The deadlock manifests with the following call chain: [<0>] device_del+0x44/0x414  <- tries to acquire same mutex [<0>] device_unregister+0x18/0x34 [<0>] rpmsg_unregister_device+0x28/0x4c [<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0 [<0>] qcom_glink_destroy_ept+0x58/0xbc [<0>] rpmsg_dev_remove+0x50/0x60 [<0>] device_remove+0x4c/0x80 [<0>] device_release_driver_internal+0x1cc/0x228 <- acquires device mutex [<0>] driver_detach+0x4c/0x98 [<0>] bus_remove_driver+0x6c/0xbc [<0>] driver_unregister+0x30/0x60 [<0>] unregister_rpmsg_driver+0x10/0x1c [<0>] fastrpc_exit+0x28/0x38 [fastrpc] [<0>] __arm64_sys_delete_module+0x1b8/0x294 [<0>] invoke_syscall+0x48/0x10c [<0>] el0_svc_common.constprop.0+0xc0/0xe0 [<0>] do_el0_svc+0x1c/0x28 [<0>] el0_svc+0x34/0x108 [<0>] el0t_64_sync_handler+0xa0/0xe4 [<0>] el0t_64_sync+0x198/0x19c The rpmsg device unregistration inside endpoint destroy is redundant. In both contexts where endpoint destruction is triggered: - Driver detach path: the driver core already tears down the rpmsg device. - Channel close path: the rpmsg device is already unregistered before endpoint destruction is reached. Remove the redundant unregistration to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93101", "url": "https://ubuntu.com/security/CVE-2026-93101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Unregister sub-device if asc_list is empty When my em28xx USB device that uses the i2c tvp5150 driver is disconnected, it crashes. The cause is that the tvp5150 i2c module uses v4l2_async, but the em28xx driver does not since it predates v4l2_async. In that corner case sd->asc_list is empty, so v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev(). Modify the code so that, if sd->asc_list is empty, v4l2_device_unregister_subdev() is still called.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89778", "url": "https://ubuntu.com/security/CVE-2026-89778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: fix out-of-bounds page array access on empty zisofs block zisofs_uncompress_block()'s empty-block fast path returns pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the decompression path which returns bytes produced relative to poffset. zisofs_fill_pages() uses that return to advance its page cursor, so when the zisofs block size is below PAGE_SIZE and a sub-page block leaves poffset partway into a page, a following empty block over-counts and advances pages[] one element past its end, after which \"if (poffset && *pages)\" reads pages[1] out of bounds. rock.c only rejects a block-size shift > 17, so a crafted \"ZF\" Rock Ridge record can set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a compressed file on such a mounted ISO9660 image. Return the byte count relative to poffset and zero only [poffset, PAGE_SIZE) of the first page, matching the decompression path. The page-aligned case (poffset == 0) is unaffected. BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290) Read of size 8 at addr ffff88800f5eac48 by task exploit/142 zisofs_read_folio (fs/isofs/compress.c:290) read_pages (mm/readahead.c:184) ... filemap_read (mm/filemap.c:2814) vfs_read (fs/read_write.c:574) __x64_sys_pread64 (fs/read_write.c:769) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address is located 0 bytes to the right of the allocated 8-byte region in the kmalloc-8 cache", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93102", "url": "https://ubuntu.com/security/CVE-2026-93102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Free RX data on late probe failure hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning. If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears down the device data without calling hfi1_free_rx(). This leaks netdev_rx and its dummy netdev. Free the RX support after IB unregistration and before postinit_cleanup(), as done on normal device removal.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93103", "url": "https://ubuntu.com/security/CVE-2026-93103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89783", "url": "https://ubuntu.com/security/CVE-2026-89783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full The depth check in xfrm6_input_addr() is off by one: if (1 + sp->len == XFRM_MAX_DEPTH) goto drop; ... sp->xvec[sp->len++] = x; xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode receive path re-enters IPv6 input via xfrm_trans_reinject() with that secpath preserved. If the inner packet carries a destination-options HAO option or a type-2 routing header, xfrm6_input_addr() is called with sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so sp->xvec[sp->len++] writes one slot past the 6-element xvec[]. The write stays within the sec_path allocation (invisible to KASAN); UBSAN_BOUNDS flags it and panics under panic_on_warn. Use \"sp->len >= XFRM_MAX_DEPTH\", matching xfrm_input(). This also restores one chain level the old check rejected at sp->len == 5. UBSAN: array-index-out-of-bounds in net/ipv6/xfrm6_input.c:309:10 index 6 is out of range for type 'xfrm_state *[6]'", "cve_priority": "medium", "cve_public_date": "2026-09-16 09:17:00 UTC" }, { "cve": "CVE-2026-93107", "url": "https://ubuntu.com/security/CVE-2026-93107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state When do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e (\"RDMA/rxe: Cleanup reset state handling in rxe_resp.c\") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return. As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it: BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+0xf36/0x1dd0 The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected. A live packet reaching the error-state check in do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93108", "url": "https://ubuntu.com/security/CVE-2026-93108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Drain RCU callbacks during module teardown IPoIB reclamation completions can be signaled from inside an RCU callback. Teardown can wake before the callback returns and unload ib_ipoib while its code is still executing. Client registration failure can also remove already-added devices and queue callbacks. Wait after client and workqueue teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93109", "url": "https://ubuntu.com/security/CVE-2026-93109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Drain RCU callbacks during module teardown devx_free_subscription() can remain queued after the last DevX event file drops its module reference or an auxiliary driver detaches its devices. mlx5_ib can then unload before the callback runs. Registration error unwind has the same risk because driver registration can attach existing devices before failing. Wait after all drivers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93110", "url": "https://ubuntu.com/security/CVE-2026-93110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Wait for RCU callbacks before unloading ib_core put_gid_ndev() is queued with call_rcu() and implemented in ib_core. Stopping the workqueues does not drain callbacks already queued, so RCU could invoke it after the module code has been unloaded. synchronize_rcu() does not wait for callbacks. Wait for them after all producers have stopped.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93113", "url": "https://ubuntu.com/security/CVE-2026-93113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK With the introduction of sync_state support in the clk and pmdomain subsystems, the following warning happens when the unused clocks are shutdown in camcc-sc8280xp: [ 15.408367] titan_top_gdsc status stuck at 'on' [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14 [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl smem hid_multitouch fuse i2c_dev [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy) [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024 [ 15.408942] Workqueue: pm pm_runtime_work [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160 [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160 [ 15.408987] sp : ffff8000800f3b40 [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000 [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88 [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002 [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101 [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001 [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000 [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000 [ 15.409098] Call trace: [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P) [ 15.409115] gdsc_disable+0x4c/0x190 [ 15.409126] _genp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93114", "url": "https://ubuntu.com/security/CVE-2026-93114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/surface: acpi-notify: Check ACPI companion before use Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 (\"ACPI: driver: Check ACPI_COMPANION() against NULL during probe\") does for the core ACPI platform drivers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93115", "url": "https://ubuntu.com/security/CVE-2026-93115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93117", "url": "https://ubuntu.com/security/CVE-2026-93117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: fix UAF when probe runs concurrent to dyn ID removal Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held, as remove_id_store can free the node. Thus, make a copy in usb_probe_interface. Clarify the documentation that the id parameter is only valid during the probe. USB serial has the same pattern, but it does not need fixing as the IDs cannot be removed via sysfs.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93118", "url": "https://ubuntu.com/security/CVE-2026-93118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: check endpoint DMA allocation ast_udc_probe() allocates a coherent DMA buffer used as the backing store for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer pointers from udc->ep0_buf, so a failed allocation is dereferenced during probe. Check the allocation before endpoint setup. The existing probe error path called ast_udc_remove(), which unregisters the gadget unconditionally and is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup helper for probe failures so pre-registration failures only unwind the resources that were actually initialized. This was found by a local static analysis checker for unchecked allocator returns while scanning Linux 6.16. The change was checked by applying it to current mainline and by running checkpatch. I do not have access to Aspeed UDC hardware, so no runtime testing was performed.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93119", "url": "https://ubuntu.com/security/CVE-2026-93119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93120", "url": "https://ubuntu.com/security/CVE-2026-93120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93126", "url": "https://ubuntu.com/security/CVE-2026-93126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_adsp: Fix reference leak for device node When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In adsp_map_carveout, it does not release the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93130", "url": "https://ubuntu.com/security/CVE-2026-93130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-base: Fix resource leak on module load failure We need to properly clean up the SMBIOS request and the privacy driver when the module load fails.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93131", "url": "https://ubuntu.com/security/CVE-2026-93131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-privacy: Fix race condition Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93136", "url": "https://ubuntu.com/security/CVE-2026-93136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize().", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93137", "url": "https://ubuntu.com/security/CVE-2026-93137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 (\"bpf: fix mm lifecycle in open-coded task_vma iterator\"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93138", "url": "https://ubuntu.com/security/CVE-2026-93138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire(). Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93140", "url": "https://ubuntu.com/security/CVE-2026-93140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: Mark LVID buffer as uptodate before marking it dirty When an I/O error occurs while writing the Logical Volume Integrity Descriptor (LVID) buffer to the block device, the block layer's completion handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the buffer. However, the buffer still contains valid LVID data in memory. If the filesystem is subsequently remounted read-write or synced, `udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call `mark_buffer_dirty()`. This triggers a spurious `WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()` because the buffer is not marked uptodate, even though its in-memory contents are valid and are about to be overwritten. To prevent this spurious warning, unconditionally set the `BH_Uptodate` flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and `udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and matches the workaround previously applied to `udf_close_lvid()` in commit 853a0c25baf9 (\"udf: Mark LVID buffer as uptodate before marking it dirty\"). Extending this workaround ensures consistent behavior across all LVID updates. Buffer I/O error on dev loop0, logical block 128, lost sync page write ------------[ cut here ]------------ !buffer_uptodate(bh) WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087 ... Call Trace: udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078 udf_reconfigure+0x336/0x540 fs/udf/super.c:679 reconfigure_super+0x232/0x8f0 fs/super.c:1080 vfs_cmd_reconfigure fs/fsopen.c:268 [inline] vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297 __do_sys_fsconfig fs/fsopen.c:463 [inline] __se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350 do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 ", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93141", "url": "https://ubuntu.com/security/CVE-2026-93141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: r8a66597: avoid double free of ep0_req in probe error path If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL. Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once. Issue found using a prototype static analysis tool and confirmed by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93142", "url": "https://ubuntu.com/security/CVE-2026-93142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/rcar: Fix error checking in probe() This code accidentally calls thermal_zone_device_enable() before checking whether thermal_zone_device_register_with_trips() failed. Move the call until later to avoid an error pointer dereference of \"priv->zone\". The driver works differently depending on if we are using OF thermal or not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and call thermal_zone_device_enable() if not. We can share same error check for if either of these fail. Moving the thermal_zone_device_enable() call is a bit cleaner as well. The original code used a three step process to cleanup: 1. Call thermal_zone_device_unregister() to cleanup. 2. Set priv->zone to an error pointer to preserve the error code. 3. Set priv->zone to NULL to avoid a second call to thermal_zone_device_unregister() in the rcar_thermal_remove() function. Now we can just do a direct goto error_unregister and rcar_thermal_remove() handles the cleanup properly.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93145", "url": "https://ubuntu.com/security/CVE-2026-93145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister() gdsc_unregister() removes the OF provider entry and tears down the parent/subdomain wiring, but never calls pm_genpd_remove() on the individual generic_pm_domain structures registered by gdsc_init(): \tvoid gdsc_unregister(struct gdsc_desc *desc) \t{ \t\tstruct device *dev = desc->dev; \t\tsize_t num = desc->num; \t\tgdsc_pm_subdomain_remove(desc, num); \t\tof_genpd_del_provider(dev->of_node); \t} That leaves dangling entries on the global gpd_list. After a provider unbind/rebind cycle (deferred-probe replay during early boot, real module unload of a clk driver that owns GDSCs, or an OF-overlay tear- down) the next gdsc_init() will end up trying to re-register a name that is still in the list and pm_genpd_init() returns -EEXIST. While we are here, flip the order so the consumer-facing OF provider entry is the first thing removed -- otherwise a fresh of_genpd_get_from_provider() call racing with the teardown could attach to a domain that is mid-removal. Iterate the scs[] array and pm_genpd_remove() each registered domain after the subdomain links are torn down. The regulators stay devm- managed (devm_regulator_get_optional() in gdsc_register()), so the release happens automatically when the underlying device is unbound; just the genpd accounting needs to be undone explicitly.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93149", "url": "https://ubuntu.com/security/CVE-2026-93149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: avoid NULL skb in stop queue drain mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately. That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb(). Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93150", "url": "https://ubuntu.com/security/CVE-2026-93150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Make nr_deadline_tasks an atomic_t The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 (\"sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets\"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road. Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch. [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93151", "url": "https://ubuntu.com/security/CVE-2026-93151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: fix response resource leak on queue teardown When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmet_rdma_send_done() and nvmet_rdma_release_rsp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs. These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows: unreferenced object 0xffff88812bc490c0 (size 32): comm \"kworker/2:1H\", pid 409, jiffies 4307744490 backtrace (crc 89afd339): __kmalloc_noprof+0x5f9/0x890 sgl_alloc_order+0x7b/0x380 nvmet_req_alloc_sgls+0x290/0x4f0 [nvmet] nvmet_rdma_map_sgl_keyed+0x241/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 unreferenced object 0xffff88814bd05e80 (size 64): comm \"kworker/3:1H\", pid 148, jiffies 4295195428 backtrace (crc e35510cb): __kmalloc_noprof+0x5f9/0x890 rdma_rw_ctx_init+0x333/0x1fa0 [ib_core] nvmet_rdma_map_sgl_keyed+0x5c8/0x12e0 [nvmet_rdma] nvmet_rdma_handle_command+0x73e/0xb80 [nvmet_rdma] __ib_process_cq+0x149/0x4c0 [ib_core] ib_cq_poll_work+0x49/0x160 [ib_core] process_one_work+0x8b2/0x1640 worker_thread+0x5fd/0xfe0 kthread+0x367/0x460 ret_from_fork+0x655/0x9d0 ret_from_fork_asm+0x1a/0x30 To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmet_rdma_free_rsp_resources() that frees up the RDMA read/write context and the request SGLs of such responses.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93152", "url": "https://ubuntu.com/security/CVE-2026-93152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Use acquire/release for queue enabled state apple_nvme_init_queue() initializes queue state and then marks the queue enabled. The interrupt and request paths check enabled before using that queue state. The old wmb() after WRITE_ONCE(enabled, true) does not publish the earlier initialization before enabled becomes visible. Use a release store when enabling the queue and acquire loads when testing it. Although the shutdown-side enabled accesses are not used for publishing queue initialization, use helpers for them as well for consistency.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93155", "url": "https://ubuntu.com/security/CVE-2026-93155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: keembay - Fix AEAD unregister count in error path register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size. Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93156", "url": "https://ubuntu.com/security/CVE-2026-93156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - fail ahash requests on HASH idle timeout rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the final DMA transfer, but ignores the poll result. If the hash engine never becomes idle, the driver still reads the digest registers and finalizes the request with the previous success value. Store the poll result and finalize the request with the timeout error before reading the digest registers.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93158", "url": "https://ubuntu.com/security/CVE-2026-93158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - stop probe if context pool creation fails sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool. Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93159", "url": "https://ubuntu.com/security/CVE-2026-93159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure The nonblocking RNG path allocates a work_data structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes. If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated work_data is not usable for producing RNG output and must not remain associated with the hwrng state. Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data. Fix this by freeing the pending work_data. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93160", "url": "https://ubuntu.com/security/CVE-2026-93160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-ecc - reject hardware ECDH without a public key The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the private key stored in the device. However, the public key is cached only after atmel_ecdh_set_secret() successfully generated that private key for the current tfm. atmel_ecdh_generate_public_key() already rejects requests when no public key is cached. Add the same check to atmel_ecdh_compute_shared_secret() to prevent the device from using a private key that was not generated for the current tfm.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93161", "url": "https://ubuntu.com/security/CVE-2026-93161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - clear AES key schedule from stack qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame. Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93162", "url": "https://ubuntu.com/security/CVE-2026-93162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - cancel work on re-enable SR-IOV timeout The QAT reset worker queues SR-IOV reenable work using a work_struct and completion embedded in an on-stack adf_sriov_dev_data. If the completion wait times out, the reset worker can return while device_sriov_wq still holds or executes the stack-backed work item. Cancel the work on the device_sriov_wq on timeout before the stack frame unwinds.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93163", "url": "https://ubuntu.com/security/CVE-2026-93163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: core - fix rng list on registration error hwrng_register(rng) does the following: 1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed. Add a list_del_init() cleanup step.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93165", "url": "https://ubuntu.com/security/CVE-2026-93165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Fix memory overread in ring handler `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93167", "url": "https://ubuntu.com/security/CVE-2026-93167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: csky: Fix a4/a5 restoration in syscall trace path The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid. The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments. This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with: mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0) Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0. Fix the trace path by loading a4/a5 from pt_regs before changing sp. Tested on: ck860f, linux-4.19.15, C-SKY abiv2", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93170", "url": "https://ubuntu.com/security/CVE-2026-93170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed. The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinx_dma_complete_descriptor() moves completed descriptors to done_list. 4. Channel is marked idle and start_transfer() is called even though active_list still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions. Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93172", "url": "https://ubuntu.com/security/CVE-2026-93172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93174", "url": "https://ubuntu.com/security/CVE-2026-93174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Copy per-CPU map value padding in copy_map_value_long() In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93177", "url": "https://ubuntu.com/security/CVE-2026-93177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup vddInd, vddciInd and mvddInd from VBIOS-parsed tables index into vddc, vddci and vddmem lookup tables without bounds checks across nine sites. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93178", "url": "https://ubuntu.com/security/CVE-2026-93178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup vddInd and vddcInd fields from VBIOS-parsed tables are used to index into voltage lookup tables without a bounds check. Return -EINVAL when any index is out of range.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93182", "url": "https://ubuntu.com/security/CVE-2026-93182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix overflow in update_tg_cfs_runnable() A divide-by-zero crash is observed when running hackbench: [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted 7.1.0-rc2+ [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0 [14697.506799] [14697.507411] __dequeue_task+0x2b4/0xc70 [14697.508677] dequeue_task_fair+0x36/0x370 [14697.509047] dequeue_task+0x101/0x2f0 [14697.509426] __schedule+0x1b1/0x1a00 [14697.510868] anon_pipe_read+0x3da/0x450 [14697.511400] vfs_read+0x361/0x390 [14697.512053] __x64_sys_read+0x19/0x30 The divide-by-zero happens here: if (scale_load_down(gcfs_rq->load.weight)) { load_sum = div_u64(gcfs_rq->avg.load_sum, scale_load_down(gcfs_rq->load.weight)); } gcfs_rq->load.weight is an insane large value and is truncated to the lower 32 bits by div_u64, which happen to be 0. Using AI for investigation, the cause is a u32 overflow in update_tg_cfs_runnable(), and flat pickup became a victim when using tg_tasks(): u32 new_sum, divider; ... new_sum = se->avg.runnable_avg * divider; <-- boom The following sequence shows how this triggers the crash: propagate_entity_load_avg() update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum __update_load_avg_cfs_rq() ___update_load_avg() # computes insane runnable_avg update_tg_load_avg() # propagates to tg->runnable_avg update_cfs_group() calc_concur_shares() tg_tasks() # long-to-int truncation, negative nr reweight_entity() # corrupted se->load.weight update_load_add() # corrupted cfs_rq->load.weight propagate_entity_load_avg() update_tg_cfs_load() div_u64() # divide-by-zero Fix by widening new_sum from u32 to u64 (no need to force tg_tasks() to return unsigned long after this fix)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93183", "url": "https://ubuntu.com/security/CVE-2026-93183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/lima: call drm_mm_init() with a valid allocation range lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93184", "url": "https://ubuntu.com/security/CVE-2026-93184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_audmix: rework runtime PM handling in probe After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang. Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle. When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93185", "url": "https://ubuntu.com/security/CVE-2026-93185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93186", "url": "https://ubuntu.com/security/CVE-2026-93186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/mbox: Clamp mailbox output allocation to the payload size CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics. The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path.", "cve_priority": "low", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93188", "url": "https://ubuntu.com/security/CVE-2026-93188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93189", "url": "https://ubuntu.com/security/CVE-2026-93189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: quiesce input in hid_hw_stop() to prevent use-after-free A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path (\"hwmon: prevent packets from going to driver for probe\", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93190", "url": "https://ubuntu.com/security/CVE-2026-93190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. \tmemcpy(caps_desc.pdo, resp->source_cap_pdos, \t sizeof(u32) * resp->source_cap_count); \t... \tmemcpy(caps_desc.pdo, resp->sink_cap_pdos, \t sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93191", "url": "https://ubuntu.com/security/CVE-2026-93191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix incorrect task context in smack_msg_queue_msgrcv The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task. In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task: ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg) In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter): ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,) However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current': smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task 'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy. Test: 1) create a sysv message queue with label “foo” 2) echo \"bar foo r\" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in \"bar\"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a \"foo\"-labeled task: \"bar\"-labeled task gets the message. This patch fixes the issue by checking permission on the 'target' task instead of 'current'. (2008-02-04, Casey Schaufler)", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93192", "url": "https://ubuntu.com/security/CVE-2026-93192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Clear queue->active_job when v3d_fence_create() fails The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.", "cve_priority": "high", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-89947", "url": "https://ubuntu.com/security/CVE-2026-89947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: meson: align gxbb_32k_clk_sel number of parents with actual count The following out-of-bounds read has been observed by Christian on a GXBB WeTek Hub: ================================================================== BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418 Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1 CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT Hardware name: WeTek Hub (DT) Call trace: show_stack+0x14/0x20 (C) dump_stack_lvl+0x74/0x94 print_report+0x164/0x4b0 kasan_report+0x98/0xd8 __asan_report_load8_noabort+0x1c/0x24 __clk_register+0x1b70/0x2418 devm_clk_hw_register+0x74/0x15c meson_clkc_init+0xd4/0x20c meson_clkc_syscon_probe+0x5c/0x94 platform_probe+0xbc/0x17c really_probe+0x184/0x844 __driver_probe_device+0x154/0x35c driver_probe_device+0x60/0x188 __driver_attach+0x168/0x4a0 bus_for_each_dev+0xec/0x180 driver_attach+0x38/0x58 bus_add_driver+0x238/0x4c0 driver_register+0x150/0x388 __platform_driver_register+0x54/0x7c gxbb_clkc_driver_init+0x18/0x20 do_one_initcall+0xb8/0x340 kernel_init_freeable+0x49c/0x52c kernel_init+0x24/0x148 ret_from_fork+0x10/0x20 The buggy address belongs to the variable: gxbb_32k_clk_parents+0x60/0x400 The buggy address belongs to a vmalloc virtual mapping The buggy address belongs to the physical page: Memory state around the buggy address: ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 >ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 ^ ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 ================================================================== Commit 7915d7d5407c (\"clk: amlogic: gxbb: drop non existing 32k clock parent\") dropped a non-existing clock parent from the gxbb_32k_clk_sel mux but didn't adjust the hard-coded num_parents field. Fix the actual number of parents of that mux by using ARRAY_SIZE instead (avoiding similar problems in future).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80671", "url": "https://ubuntu.com/security/CVE-2026-80671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf sched: Fix register_pid() overflow, strcpy, and BUG_ON register_pid() has several issues when processing untrusted perf.data: 1. Integer overflow: (pid + 1) * sizeof(struct task_desc *) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop. 2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMM_LEN buffer with no length check. 3. BUG_ON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process. 4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nr_tasks incremented before the realloc, leaving corrupted state on failure. Cap pid at PID_MAX_LIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUG_ON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-93203", "url": "https://ubuntu.com/security/CVE-2026-93203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: avoid CRC corruption due to parallel claim add batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the \"new\" claim code was running in parallel to the \"change backbone\" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the \"new\" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-93204", "url": "https://ubuntu.com/security/CVE-2026-93204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both.", "cve_priority": "medium", "cve_public_date": "2026-09-17 17:18:00 UTC" }, { "cve": "CVE-2026-23137", "url": "https://ubuntu.com/security/CVE-2026-23137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: unittest: Fix memory leak in unittest_data_add() In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak. Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths. For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.", "cve_priority": "low", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-89970", "url": "https://ubuntu.com/security/CVE-2026-89970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: Synchronize timeout work during SQ teardown nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-64210", "url": "https://ubuntu.com/security/CVE-2026-64210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix unlocked writing to ICOSQ During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected. There are 2 such races: A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napi_complete_done(). At this point the NAPI can be scheduled on a different CPU. Like this: CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napi_complete_done() clears SCHED mlx5e_cq_arm(...) napi_schedule_prep() sets SCHED mlx5e_napi_poll() mlx5e_xsk_alloc_rx_mpwqe() mlx5e_icosq_sync_lock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5e_trigger_irq(&c->icosq) wqe_info[pi] = {NOP, 1} mlx5e_post_nop() advances sq->pc B) mlx5e_trigger_irq() is called on the ICOSQ when mlx5e_trigger_napi_icosq() is running. The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked. This issue was noticed in the wild with the following splat: netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:826 [...] [...] Call Trace: mlx5e_napi_poll+0x11d/0x7f0 [mlx5_core] __napi_poll+0x30/0x200 ? skb_defer_free_flush+0x9c/0xc0 net_rx_action+0x2fe/0x3f0 handle_softirqs+0xd8/0x340 __irq_exit_rcu+0xbc/0xe0 common_interrupt+0x85/0xa0 asm_common_interrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5_core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-89794", "url": "https://ubuntu.com/security/CVE-2026-89794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: zero pipe read compound padding Compound response handling extends the last response iov to an eight-byte boundary. smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory. Allocate the aligned size and clear the unused tail before pinning the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-90015", "url": "https://ubuntu.com/security/CVE-2026-90015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-80878", "url": "https://ubuntu.com/security/CVE-2026-80878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix leak of ungot volume Fix afs_lookup_volume_rcu() so that it doesn't leak a dying volume if afs_try_get_volume() fails.", "cve_priority": "medium", "cve_public_date": "2026-09-04 17:16:00 UTC" }, { "cve": "CVE-2026-89800", "url": "https://ubuntu.com/security/CVE-2026-89800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE A successful OP_UNMAP_SPARSE marks its region dirty with nouveau_uvma_region_dirty() and defers the teardown to nouveau_uvmm_bind_job_cleanup(); it does not remove the region from uvmm->region_mt. If a later op in the job fails, the unwind path never clears reg->dirty (set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup skips the teardown. The region is left in the tree with dirty set and its completion never signalled. Later binds over that range then fail permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable wait_for_completion() in bind_validate_region() -- for the lifetime of the uvmm. Clear reg->dirty when the unwind reverts the sparse unmap, restoring the region to the state it was found in.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89801", "url": "https://ubuntu.com/security/CVE-2026-89801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set from nouveau_uvma_region_find(), which only looks the region up and takes no reference; a region's sole reference is its membership in uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure. The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears op->reg; these two do not. unwind_continue steps back one op, so the failing op is skipped by the unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup() then enters its if (op->reg) branch and calls nouveau_uvma_region_remove() and nouveau_uvma_region_put() on it, dropping the tree's sole reference and freeing a region this job never created. The comment above the cleanup loop documents the broken invariant: op->reg must be NULL on submit failure. This frees a live region on an unrelated failure, reachable single-job when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns the same region, its cleanup then removes and puts the freed region, a use-after-free. Clear op->reg on both failure paths.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89802", "url": "https://ubuntu.com/security/CVE-2026-89802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(), and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates a region, so op->ops stays NULL for a successfully processed sparse map. If a later op in the same job fails, the reverse unwind loop revisits that op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally. drm_gpuva_ops_free() dereferences its argument right away (list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is DRM_RENDER_ALLOW. Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup() already does for the identical free.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89803", "url": "https://ubuntu.com/security/CVE-2026-89803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: unsubscribe the channel-kill event before the fence context nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown: \tif (chan->fence) \t\tnouveau_fence(chan->cli->drm)->context_del(chan); \t... \tnvif_object_dtor(&chan->vram); \tnvif_event_dtor(&chan->kill); The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed. Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it. Drop the subscription before anything it depends on is torn down.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89816", "url": "https://ubuntu.com/security/CVE-2026-89816", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used Commit 1c6ceeee6ebb (\"drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits\") fixed a very similar issue when the event was allocated by drm_atomic_helper_setup_commit() itself. However, if the event is allocated in prepare_signaling(), it will also be set to NULL in complete_signaling(), which prevents drm_crtc_commit from being put in __drm_atomic_helper_crtc_destroy_state(). Dropping the reference when the event is set to NULL at complete_signaling() fixes the leak. The leak can be reproduced by sending a signal to the thread using DRM_MODE_PAGE_FLIP_EVENT and using a sw_sync fence to cause the atomic ioctl to block at drm_atomic_helper_wait_for_fences(). It happened both with amdgpu and vkms.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89817", "url": "https://ubuntu.com/security/CVE-2026-89817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gud: NUL-terminate TV mode names read from the device gud_connector_add_tv_mode() reads a buffer of fixed-size mode names from the USB device and passes pointers into it to drm_mode_create_tv_properties_legacy(), which calls strlen() on each one. Nothing guarantees the device NUL-terminates a name, so strlen() can run past the end of a slot and, for the last mode, past the end of the allocation. Terminate each name at the end of its slot before use.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89818", "url": "https://ubuntu.com/security/CVE-2026-89818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier \"header does not fit in BO\" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89819", "url": "https://ubuntu.com/security/CVE-2026-89819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: validate plane degamma LUT size for private color prop Unlike the CRTC degamma path, which is guarded by amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never validated before use. __set_dm_plane_degamma() passed the user-supplied size straight into __is_lut_linear() and, for a non-linear LUT, into __set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size. A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already asserts a few lines below (and which the CRTC path enforces). The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with AMD_PRIVATE_COLOR defined.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89821", "url": "https://ubuntu.com/security/CVE-2026-89821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with \texpected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89822", "url": "https://ubuntu.com/security/CVE-2026-89822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Guard against NULL driver_data in i915_pci_probe() pci_match_device() can return the dummy pci_device_id_any entry when a device is force-bound via sysfs driver_override, in which case ->driver_data is unset (NULL). i915_pci_probe() casts it to struct intel_device_info * unconditionally and dereferences intel_info->require_force_probe, causing a NULL-ptr-deref. (cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89823", "url": "https://ubuntu.com/security/CVE-2026-89823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: fix race between partial drm_dev_register() failure and ioctl If drm_dev_register() fails after registering a minor (e.g. render minor registered, primary minor fails), userspace could have opened the first minor and entered a drm_dev_enter() critical section. Since the unplugged flag was never set, the ioctl proceeds while the error path tears down device resources. Fix this by introducing drm_dev_synchronize_unplug(), which sets the unplugged flag and waits for the SRCU barrier, ensuring all in-flight drm_dev_enter() critical sections complete before cleanup proceeds; call it on the error path of drm_dev_register().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89824", "url": "https://ubuntu.com/security/CVE-2026-89824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-edp: fix i2c adapter leak on probe failure Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89830", "url": "https://ubuntu.com/security/CVE-2026-89830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix valid block count leak on data block allocation failure In __allocate_data_block(), when allocating a new data block (dn->data_blkaddr == NULL_ADDR), inc_valid_block_count() is called first to increment total_valid_block_count and i_blocks. If the subsequent f2fs_allocate_data_block() fails, the function returns the error directly without rolling back the already-incremented block counts, causing a permanent leak. Fix this by calling dec_valid_block_count() to undo the increment before returning the error. The condition old_blkaddr == NULL_ADDR precisely identifies the case where inc_valid_block_count() was called.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89834", "url": "https://ubuntu.com/security/CVE-2026-89834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89835", "url": "https://ubuntu.com/security/CVE-2026-89835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid NULL checkpoint thread access in sysfs checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs. The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer. Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89839", "url": "https://ubuntu.com/security/CVE-2026-89839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set() f2fs_xattr_advise_set() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing the \"system.advise\" xattr to be set, instead of the idmap that the VFS passes to the ->set() handler. f2fs supports idmapped mounts, so on such a mount this checks the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EPERM and an unrelated caller wrongly allowed. Pass the handler's idmap instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89842", "url": "https://ubuntu.com/security/CVE-2026-89842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started qla_nvme_xmt_ls_rsp() bails out to the out: label when firmware is not started (!ha->flags.fw_started), but the out: path unconditionally calls qla_nvme_ls_reject_iocb(), which ends in qla2x00_start_iocbs() and an unconditional doorbell write to the request queue in-pointer register. This rings the firmware doorbell and queues an IOCB that stopped or resetting firmware cannot consume, and touches MMIO during the reset/EEH window where fw_started is also clear. Only emit the LS reject IOCB (and ring the doorbell) when fw_started is set; otherwise just clean up and return. The post-allocation failure cases (SRB alloc / qla2x00_start_sp() failure) run with firmware started and still send the reject. Apply the same guard to the reject emission in qla2xxx_process_purls_pkt().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89843", "url": "https://ubuntu.com/security/CVE-2026-89843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak Several bsg handlers stage their request/reply in an uninitialized 256-byte on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via sg_copy_to_buffer(), which only copies as many bytes as the user-supplied request payload. When the request is shorter than the structure, the remainder of the buffer is left holding stale stack data. qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full structure back to the reply payload with sg_copy_from_buffer(), leaking the uninitialized stack bytes to user space. The write/update paths do not copy the buffer back, but can feed uninitialized fields to the device. Zero the stack buffer at declaration in all five handlers, mirroring the heap kzalloc() approach, so short requests can no longer expose stale memory.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89844", "url": "https://ubuntu.com/security/CVE-2026-89844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport_slock for host map update in report ID acquisition qla24xx_report_id_acquisition() format-1 handling drops vport_slock after taking the vport reference and then calls qla_update_host_map() without the lock. That reaches qla_update_vp_map(), which mutates the ha->host_map btree via btree_insert32()/btree_update32()/btree_remove32() and is documented to require vport_slock to be held by the caller. Running it unlocked can race concurrent host_map updates and corrupt the btree. The format-2 path in the same function already wraps its host_map update (SET_AL_PA) in vport_slock; the format-1 path is the lone outlier. Hold vport_slock across the format-1 qla_update_host_map() call to honor the documented locking contract. The vref_count taken in the loop keeps the vport valid, so this only adds the missing host_map serialization.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89845", "url": "https://ubuntu.com/security/CVE-2026-89845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry() qla2x00_error_entry() reads ha->req_q_map[que] twice: once for the NULL check and again when assigning it to req. The map slot is cleared by qla25xx_free_req_que() (ha->req_q_map[que_id] = NULL under mq_lock) during queue teardown, while the response-queue interrupt that drives qla2x00_error_entry() is still registered (the IRQ is released later in qla25xx_free_rsp_que()). If the slot is set to NULL between the two reads, req becomes NULL and is dereferenced. Read the slot once into req and NULL-check the local before use. mq_lock is a mutex and cannot be taken from interrupt context, so the single read plus local check is the appropriate fix for the reported NULL dereference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89846", "url": "https://ubuntu.com/security/CVE-2026-89846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read In qla2x00_status_entry(), the FWI2 status path advances sense_data and shrinks par_sense_len by rsp_info_len: \tif (IS_FWI2_CAPABLE(ha)) { \t\tsense_data += rsp_info_len; \t\tpar_sense_len -= rsp_info_len; \t} rsp_info_len is a 32-bit value taken directly from the target's FCP response (sf.rsp_data_len), while par_sense_len is the IOCB data area size (28 bytes for 24xx, 60 bytes for 29xx). A hostile or buggy target reporting an rsp_info_len larger than par_sense_len makes the unsigned subtraction underflow to a huge value and advances sense_data out of bounds. The underflowed par_sense_len then defeats the cap in qla2x00_handle_sense(): \tif (sense_len > par_sense_len) \t\tsense_len = par_sense_len; \tmemcpy(cp->sense_buffer, sense_data, sense_len); so the memcpy reads up to SCSI_SENSE_BUFFERSIZE bytes from the out-of-bounds sense_data pointer, leaking adjacent response-ring/heap memory into the command's sense buffer. Clamp rsp_info_len to par_sense_len before the subtraction so par_sense_len can never underflow and sense_data stays within the IOCB data area. The fix sits before the comp_status switch, covering both qla2x00_handle_sense() call sites.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89847", "url": "https://ubuntu.com/security/CVE-2026-89847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Avoid double completion in async IOCB timeout qla2x00_async_iocb_timeout() tries to abort a timed-out async IOCB. When qla24xx_async_abort_cmd() fails, both the SRB_LOGIN_CMD path and the SRB_CTRL_VP/default path scan outstanding_cmds[] for the SRB and then call sp->done(sp, QLA_FUNCTION_TIMEOUT) unconditionally, without checking whether the SRB was actually found and removed. If the response ISR completes the same handle first, it removes the SRB under qp_lock_ptr and runs sp->done() -> complete(sp->comp). The submitter qla24xx_control_vp() wakes from wait_for_completion(), clears sp->comp, drops its reference and returns, reclaiming the on-stack completion. The timer reference keeps the SRB alive across the timeout handler, but not the submitter's stack. The timeout then issues a second sp->done() -> qla_ctrlvp_sp_done(), which evaluates \"if (sp->comp) complete(sp->comp)\"; with the pointer loaded before the submitter's NULL store, complete() writes into the freed stack frame, a use-after-free. Track whether this path removed the SRB from outstanding_cmds and only call sp->done() when it did, so the command is completed exactly once by whichever path owns it. This mirrors the sp_found guard already used in qla24xx_abort_iocb_timeout().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89848", "url": "https://ubuntu.com/security/CVE-2026-89848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Quiesce response IRQ before freeing request queue qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free. The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req. Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89849", "url": "https://ubuntu.com/security/CVE-2026-89849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path qla2x00_status_entry() filters out non-TYPE_SRB entries and the SRB_NVME_CMD, SRB_BIDI_CMD and SRB_TM_CMD types, then falls through to a SCSI fast path that assumes the command is an SRB_SCSI_CMD. The first thing on that path, qla_chk_edif_rx_sa_delete_pending(), and the subsequent handling both evaluate GET_CMD_SP(sp), i.e. sp->u.scmd.cmd. The srb u union overlays the SCSI command pointer with other command layouts (bsg_job, iocb_cmd). If firmware delivers an unexpected STATUS_TYPE IOCB for a non-SCSI handle, sp->u.scmd.cmd can read as a non-NULL garbage pointer, bypassing the NULL checks in qla_chk_edif_rx_sa_delete_pending() and at the cp == NULL test, and leading to a wild pointer dereference. Reject any SRB whose type is not SRB_SCSI_CMD before entering the fast path. The outstanding_cmds slot is left untouched so a genuinely non-SCSI command still completes through its proper handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89850", "url": "https://ubuntu.com/security/CVE-2026-89850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Don't query firmware state while chip is down qla2x00_fw_state_show() initializes rval to QLA_FUNCTION_FAILED and jumps to the out: label when the chip is down or EEH is busy. The out: block then re-issued qla2x00_get_firmware_state() because rval != QLA_SUCCESS, defeating the chip-down/EEH-busy guards and issuing a mailbox command (outside optrom_mutex) during ISP reset or PCI error recovery, which can hang the adapter. It also turned a normal in-lock mailbox failure into a second unsynchronized mailbox attempt. Make the out: fallback only mark the firmware state as unknown. The mailbox is now issued at most once, inside optrom_mutex, and only when the chip is up and not EEH-busy.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89851", "url": "https://ubuntu.com/security/CVE-2026-89851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace enable parsing in debugfs qla2x00_dfs_fce_write() called kstrtoul() with a NULL result pointer, so a successful parse would dereference NULL and oops. Worse, the int return value (0 on success, negative errno on failure) was assigned to the unsigned long enable flag, inverting the intended logic: a valid number was treated as \"disable\" while a parse failure enabled FCE. Parse the value into enable and propagate parse errors to userspace.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89852", "url": "https://ubuntu.com/security/CVE-2026-89852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state() The mbx_cmd_t is allocated on the stack but left uninitialized. qla2x00_mailbox_command() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00_get_firmware_state() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value. On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fw_state and mpi_fw_state sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89853", "url": "https://ubuntu.com/security/CVE-2026-89853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump qla2x00_free_fce_trace() freed and cleared ha->fce while holding only fce_mutex. The firmware-dump consumers qla27xx_fwdt_entry_t264() and qla25xx_copy_fce() read ha->fce (NULL check followed by a copy of the buffer) under hardware_lock and never take fce_mutex. A debugfs FCE disable could therefore free the DMA buffer between a dump's NULL check and its copy, resulting in a use-after-free. Unpublish ha->fce under hardware_lock, then release the lock and free the DMA buffer (dma_free_coherent() may sleep). A concurrent dump either completes its check and copy with the buffer still valid, or observes ha->fce == NULL and skips it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89854", "url": "https://ubuntu.com/security/CVE-2026-89854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix cs84xx use-after-free on host teardown qla84xx_put_chip() drops the last reference to ha->cs84xx and frees it via __qla84xx_chip_release() without clearing ha->cs84xx. During teardown it ran before scsi_remove_host(), which is what removes the 84xx_fw_version host sysfs attribute. A concurrent read of that attribute in the window between the two calls executes qla24xx_84xx_fw_version_show(), which dereferences the freed ha->cs84xx, resulting in a use-after-free. Move qla84xx_put_chip() to after scsi_remove_host() in both qla2x00_remove_one() and qla2x00_disable_board_on_pci_error(). Once scsi_remove_host() returns, the sysfs attribute is gone and kernfs has drained any in-flight show(), so no reader can touch cs84xx; the put still runs before the host and ha are freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89855", "url": "https://ubuntu.com/security/CVE-2026-89855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize flash version read in reset handler The \"update cache versions without reset\" sysfs reset operation (0x20261) calls get_flash_version(), which reads hardware flash registers, without holding ha->optrom_mutex. The VPD update path serializes the same call under optrom_mutex, so this reset path can interleave its flash register accesses with a concurrent VPD or optrom flash operation and corrupt the reads. Hold ha->optrom_mutex across the get_flash_version() call to match the VPD update path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89856", "url": "https://ubuntu.com/security/CVE-2026-89856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation ha->msix_count is u16, but ha->max_req_queues, ha->max_rsp_queues and ha->max_qpairs are u8. Deriving the queue count as \"ha->max_req_queues = ha->msix_count - 1\" therefore truncates: a board (or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X count of 1 zeroes it as well, and in target mode the subsequent \"ha->max_req_queues--\" then underflows 0 to 255. When the count is 0, qla2x00_alloc_queues() calls kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is not NULL, so the allocation check passes and the following \"ha->req_q_map[0] = req\" dereferences ZERO_SIZE_PTR, corrupting memory or crashing the kernel. Add qla_calc_queue_count() to clamp the derived value into [1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and use it at all three derivation sites (qla25xx_iospace_config(), qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the target-mode decrement so it cannot reintroduce a zero (which would in turn underflow max_qpairs).", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89857", "url": "https://ubuntu.com/security/CVE-2026-89857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject qla_nvme_ls_reject_iocb() allocates from and advances the request ring through __qla2x00_alloc_iocbs() (which assumes the hardware_lock is held) and qla2x00_start_iocbs() (which advances the ring and rings the request-in doorbell), but takes no lock itself. Two of its callers invoke it without the producer lock held: - qla_nvme_xmt_ls_rsp(), the NVMe-FC .xmt_ls_rsp transport callback, on its error path, and - qla2xxx_process_purls_pkt(), run from the purex work/DPC context. Both use ha->base_qpair, whose qp_lock_ptr is hardware_lock, so they can run concurrently with normal I/O submission on the base ring and corrupt the ring producer state, leading to duplicated or dropped commands. The third caller, qla2xxx_process_purls_iocb(), runs inside qla24xx_process_response_queue() with the qpair lock already held and is safe; that is also why the lock cannot be taken inside the helper itself (it would recursively re-acquire hardware_lock on the response path). Take qp_lock_ptr around the two unlocked callers and document the helper as caller-locked. Both run in process context, so spin_lock_irqsave() is used and nothing in the locked region sleeps.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89858", "url": "https://ubuntu.com/security/CVE-2026-89858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions() qla2x00_update_fru_versions() copies the user-supplied BSG request into a fixed 256-byte stack buffer (bsg[DMA_POOL_SIZE]) and then iterates list->count times over the qla_image_version array embedded in that buffer, advancing the image pointer each iteration. count is taken directly from user input with no upper bound, while only (DMA_POOL_SIZE - sizeof(list->count)) / sizeof(struct qla_image_version) = 6 entries actually fit. A larger count walks the image pointer off the end of the stack buffer, reading adjacent kernel stack memory and sending it to the device via qla2x00_write_sfp(). Reject requests whose declared count does not fit in the buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89860", "url": "https://ubuntu.com/security/CVE-2026-89860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Initialize NVMe abort_work once at submission qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker. Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89861", "url": "https://ubuntu.com/security/CVE-2026-89861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition() In the format 1 path, the virtual port is located on ha->vp_list while holding vport_slock, but the lock is dropped before vp is used: qla_update_host_map() is called and VP_IDX_ACQUIRED/REGISTER_FC4_NEEDED/ REGISTER_FDMI_NEEDED are set on vp. No reference is taken across that window, so a concurrent qla24xx_deallocate_vp_id() can tear the vport down and free it, leading to a use-after-free. Take a vport reference (vref_count) under vport_slock when the matching vp is found, and drop it after the last use of vp. qla24xx_deallocate_vp_id() waits for vref_count to reach zero before unlinking and freeing the vport, so the pointer stays valid. This matches the reference idiom already used by the other ha->vp_list traversals.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89863", "url": "https://ubuntu.com/security/CVE-2026-89863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check qla_chk_edif_rx_sa_delete_pending() obtains the SCSI command via GET_CMD_SP(sp) and immediately dereferences cmd->sc_data_direction. That command pointer can be NULL: the firmware may post a status completion for a command that has already been returned or aborted. The caller qla2x00_status_entry() acknowledges this on the very same status path, re-fetching GET_CMD_SP(sp) and bailing out with the \"Command already returned\" message when it is NULL -- but that check runs only after qla_chk_edif_rx_sa_delete_pending() has already dereferenced the pointer, so a NULL cmd crashes the kernel in interrupt context. Return early when cmd is NULL, before touching cmd->sc_data_direction.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89864", "url": "https://ubuntu.com/security/CVE-2026-89864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: \tstruct qla_i2c_access { \t\tuint16_t device, offset, option, length; \t\tuint8_t buffer[0x40]; \t} __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89865", "url": "https://ubuntu.com/security/CVE-2026-89865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers The FRU and I2C bsg handlers stage their transfer in a DMA_POOL_SIZE (256-byte) bounce buffer obtained from dma_pool_alloc(), which does not zero the allocation. They initialize only a few leading bytes before handing the buffer to qla2x00_write_sfp(). qla2x00_write_sfp() can override the transfer length with a user-supplied value: \tif (len == 1) \t\topt |= BIT_0; \tif (opt & BIT_0) \t\tlen = *sfp; *sfp is the first byte of the (user-controlled) payload, so len can grow up to 255. The device then DMA-reads len bytes from the 256-byte pool buffer. Since only a small prefix was written (e.g. MAX_FRU_SIZE == 36 bytes for a FRU version, one byte for a FRU status register), the hardware reads past the initialized region and writes up to ~219 bytes of stale DMA-pool heap memory to the device flash. Allocate the buffer with dma_pool_zalloc() in all five FRU/I2C handlers so any bytes beyond the initialized data are zero rather than stale heap contents.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89870", "url": "https://ubuntu.com/security/CVE-2026-89870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: zoran: Avoid freeing a registered video_device twice zoran_init_video_device() installs zoran_vdev_release() as the video_device release callback through zoran_template. After video_register_device() succeeds, video_unregister_device() drops the registered video_device reference and the V4L2 core eventually invokes that release callback, which kfree()s the video_device. zoran_exit_video_devices() called video_unregister_device() and then kfree(zr->video_dev), so device teardown could free the same video_device twice. Remove the direct kfree() and clear the cached pointer after unregistering. The pre-registration failure path keeps its manual free because the video_device was not registered there. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89871", "url": "https://ubuntu.com/security/CVE-2026-89871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure kthread_run() returns an ERR_PTR on failure, not NULL. When start_streaming() fails, data->kthread_vid_cap is left holding this error pointer instead of being cleared. This causes two subsequent bugs: 1. A future call to start_streaming() sees a non-NULL kthread_vid_cap and returns 0 (success) immediately, without actually starting the capture thread. 2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which is false for an error pointer, and proceeds to call kthread_stop() on the error pointer, leading to a kernel crash. Fix this by resetting kthread_vid_cap to NULL on failure before jumping to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89872", "url": "https://ubuntu.com/security/CVE-2026-89872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link In v4l2_fwnode_parse_link(), the remote endpoint fwnode reference is acquired using fwnode_graph_get_remote_endpoint(). This reference is properly released in the error paths, but it is leaked on the success path. Add the missing fwnode_handle_put() before returning 0 to prevent the reference leak. [Sakari Ailus: Fix subject prefix and coding style a little.]", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89874", "url": "https://ubuntu.com/security/CVE-2026-89874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: avoid deleting unlinked ASC entry on link error v4l2_async_match_notify() creates ancillary media links before adding asc->asc_subdev_entry to sd->asc_list. If ancillary link creation fails, the function jumps to err_call_unbind while asc_subdev_entry has not been linked yet. Async connections are zero-allocated, so the list entry still has NULL next and prev pointers on this path. Calling list_del() on it can therefore dereference NULL instead of returning the original link creation error. Do not delete asc_subdev_entry from err_call_unbind. There is no list insertion to undo on this path; the bound callback and sub-device registration are the operations that need to be rolled back.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89876", "url": "https://ubuntu.com/security/CVE-2026-89876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89877", "url": "https://ubuntu.com/security/CVE-2026-89877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: fix cleanup on resource allocation failure saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions. If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list. Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning. Also release BAR0 if it was successfully requested but the BAR2 request fails.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89878", "url": "https://ubuntu.com/security/CVE-2026-89878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: check firmware size before reading trailing marker s2255_probe() reads a 4-byte marker and version from the last 8 bytes of the firmware blob (fw->data[fw_size - 8] and [fw_size - 4]). If the firmware file is shorter than 8 bytes, fw_size - 8 underflows and the access reads out of bounds. Validate the firmware size before indexing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89879", "url": "https://ubuntu.com/security/CVE-2026-89879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s2255: bound JPEG frame size before copying into the buffer s2255_fillbuff() memcpy()s vc->jpg_size bytes of a captured JPEG/MJPEG frame into the vb2 plane. vc->jpg_size is taken verbatim from the S2255_MARKER_FRAME header the device sends (pdword[4] in save_frame()) and, unlike the frame payload length just above it, is never bounded: \tpayload = le32_to_cpu(pdword[3]); \tif (payload > vc->req_image_size)\t/* payload is checked ... */ \t\treturn -EINVAL; \tvc->pkt_size = payload; \tvc->jpg_size = le32_to_cpu(pdword[4]);\t/* ... jpg_size is not */ A malicious or malfunctioning device can therefore report a jpg_size larger than the destination vb2 plane, and the memcpy() writes past it. jpg_size is a signed int, so a value with the top bit set also turns into a huge length. Reject a frame whose jpg_size is negative or exceeds the plane size before copying it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89880", "url": "https://ubuntu.com/security/CVE-2026-89880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: release URBs and stream buffers on start_streaming() failure rtl2832_sdr_start_streaming() calls rtl2832_sdr_alloc_stream_bufs(), rtl2832_sdr_alloc_urbs() and rtl2832_sdr_submit_urbs() in sequence and shares a single err: label that only unlocks the mutex and returns. When alloc_urbs() succeeds but submit_urbs() fails, or when alloc_urbs() itself returns -ENOMEM after alloc_stream_bufs() has already succeeded, the URBs and/or the coherent DMA stream buffers stay allocated while streaming reports failure to vb2. Two latent defects follow on the next VIDIOC_STREAMON: 1) rtl2832_sdr_alloc_stream_bufs() unconditionally resets dev->buf_num to 0 and overwrites dev->buf_list[]/dev->dma_addr[], permanently leaking the coherent DMA memory allocated by the previous attempt. 2) rtl2832_sdr_alloc_urbs() never resets dev->urbs_initialized and only increments it. After a second successful pass urbs_initialized can exceed MAX_BULK_BUFS, so the subsequent rtl2832_sdr_free_urbs() walks from urbs_initialized - 1 down to 0 and reads past the end of dev->urb_list[], passing garbage pointers to usb_free_urb(). Mirror the teardown that stop_streaming() already performs: on the error path call rtl2832_sdr_free_urbs() and rtl2832_sdr_free_stream_bufs() before unlocking. Both helpers are idempotent (free_urbs kills and zeros urbs_initialized; free_stream_bufs is gated on URB_BUF and clears the buf_num counter), so partial-failure paths and the no-allocation paths remain safe. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89881", "url": "https://ubuntu.com/security/CVE-2026-89881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix DMA leak rtl2832_sdr_remove() runs on USB disconnect and clears dev->udev to NULL before any pending streaming teardown has run. When user space later closes its file descriptor, vb2 calls rtl2832_sdr_stop_streaming() which in turn calls rtl2832_sdr_free_stream_bufs(). That helper releases each coherent buffer with: usb_free_coherent(dev->udev, dev->buf_size, dev->buf_list[dev->buf_num], dev->dma_addr[dev->buf_num]); usb_free_coherent() returns immediately when its dev argument is NULL, so every DMA stream buffer that was live at disconnect is silently leaked. The URBs allocated in rtl2832_sdr_alloc_urbs() outlive the device for the same reason. The rtl2832_sdr driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&dev->vdev) with vb2_video_unregister_device(&dev->vdev) and move it before clearing dev->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs rtl2832_sdr_stop_streaming() if streaming is active, so URBs and coherent DMA stream buffers are freed while dev->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&dev->vb_queue_lock) / mutex_lock(&dev->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around dev->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89883", "url": "https://ubuntu.com/security/CVE-2026-89883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: sunxi-cir: Unregister rc device on probe failure After rc_register_device() succeeds, later probe failures must undo the registration with rc_unregister_device(). The current error path jumps to the allocation cleanup label and only calls rc_free_device(), leaving the rc device registration and resources created by rc_register_device() behind. Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rc_free_device() for failures before rc_register_device() succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89884", "url": "https://ubuntu.com/security/CVE-2026-89884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89887", "url": "https://ubuntu.com/security/CVE-2026-89887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov7740: fix use-after-destroy in remove The ov7740_remove() function had a severe teardown order bug where it destroyed the driver's mutex before freeing the V4L2 control handler which relies on that mutex, leading to a use-after-destroy kernel panic. Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and mutex_destroy() sequentially, but then called ov7740_free_controls() which invokes both of them a second time, resulting in a double-free. This patch fixes the issue by unregistering the subdevice first, and relying exclusively on ov7740_free_controls() to safely tear down the mutex and control handler in the correct order.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89888", "url": "https://ubuntu.com/security/CVE-2026-89888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov02a10: fix endpoint parsing use-after-free The ov02a10_check_hwcfg() function calls fwnode_handle_put(ep) immediately after allocating and parsing the endpoint. However, it subsequently calls fwnode_property_read_u32() using the same 'ep' handle, leading to a potential use-after-free. Additionally, reading the optional 'ovti,mipi-clock-voltage' property used to overwrite the 'ret' variable. If the property was missing, 'ret' would become negative, and this failure code would be incorrectly returned at the end of the function, causing probe to fail entirely. Fix the use-after-free by moving fwnode_property_read_u32() before the endpoint is parsed and freed. Avoid the error leak by not assigning the result of fwnode_property_read_u32() to 'ret'.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89890", "url": "https://ubuntu.com/security/CVE-2026-89890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: go7007: defer the ALSA v4l2 put until card release go7007_snd_init() already takes a v4l2_device reference for the ALSA side, but go7007_snd_remove() drops it immediately after calling snd_card_free_when_closed(). That is too early when a userspace process still has the capture PCM open. The ALSA card and its PCM callbacks remain alive until the last file is closed, so the release path can still reach struct go7007 through pcm->private_data and call go7007_snd_hw_free() after the V4L2 release path has freed the object. Move the matching v4l2_device_put() to the ALSA card private_free callback so the existing ALSA reference covers the whole deferred card lifetime.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89891", "url": "https://ubuntu.com/security/CVE-2026-89891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free of dev_next->devlist on disconnect When a device with has_dual_ts=1 is probed and the is_audio_only path is taken, both dev and dev->dev_next are added to the global em28xx_devlist via em28xx_init_extension(). However, during disconnect, em28xx_close_extension(dev) only calls list_del(&dev->devlist), leaving dev->dev_next->devlist still linked in the global list. When dev_next is subsequently freed via kref_put(), its devlist entry becomes a dangling pointer in em28xx_devlist. The next device probe that calls em28xx_init_extension() triggers a list corruption BUG when list_add_tail detects the freed node. This bug was exposed by commit a368ecde8a50 (\"USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor\") which clears reserved bits in bEndpointAddress during endpoint parsing. This causes fuzzed endpoint addresses like 0xf3 to be normalized to 0x83, which em28xx interprets as a vendor audio endpoint, enabling the is_audio_only + has_dual_ts code path that was previously unreachable with such descriptors. Fix this by removing dev->dev_next->devlist from the global list in em28xx_close_extension() before the device is freed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89892", "url": "https://ubuntu.com/security/CVE-2026-89892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: defer audio-only extension registration The audio-only path registers extensions while probing the primary device. For a dual-TS board, this happens before dev_next is created. The duplicate device inherits is_audio_only and is then independently inserted into em28xx_devlist. The list is intended to contain only primary devices: extension operations reach the secondary device through dev_next. The independently linked secondary can be freed during disconnect while its list node remains reachable, resulting in a use-after-free. Defer audio-only extension registration to the module-request work item. It runs only after probing has completed construction of the optional secondary device, so only the primary is registered and extension callbacks reach the secondary through dev_next.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89893", "url": "https://ubuntu.com/security/CVE-2026-89893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: cancel NetUP CI work before teardown netup_ci_exit() frees a netup_ci_state while its work item, netup_read_ci_status(), may still be pending or running on the system workqueue. The worker obtains the state with container_of() and dereferences it, so it must not outlive the state. netup_ci_init() queues the initial status read, and CI GPIO interrupts subsequently queue the same work from netup_ci_slot_status(). During remove, cx23885_finidev() calls free_irq() before the CI device is unregistered. free_irq() prevents further IRQ handlers from running, but does not drain work queued previously, so the worker can run after netup_ci_exit() frees the state. Call cancel_work_sync() before dvb_ca_en50221_release() and kfree(). This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89894", "url": "https://ubuntu.com/security/CVE-2026-89894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: reject geometry changes while the VBI queue is busy vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the *video* queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the *live* dev->width and the latched lines_per_field on every URB completion: \toffset = lines_completed * (dev->width << 1) + ...; \tif (dma_q->current_field == 2) \t\toffset += dev->width * 2 * dma_q->lines_per_field; \tmemcpy(plane + offset, p_buffer, lencopy); Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer. Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89895", "url": "https://ubuntu.com/security/CVE-2026-89895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cobalt: Avoid freeing ALSA private data twice snd_cobalt_card_create() stores cobsc in sc->private_data and installs snd_cobalt_card_private_free() as sc->private_free. From that point, snd_card_free(sc) releases cobsc through the ALSA card cleanup path. If cobalt_alsa_init() fails after snd_cobalt_card_create(), the err_exit_free path calls snd_card_free(sc) and then kfree(cobsc). That second free releases the same object again. Remove the explicit kfree(cobsc) and leave ownership with the ALSA card. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89896", "url": "https://ubuntu.com/security/CVE-2026-89896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: fix memory leak in cedrus_init_ctrls() In cedrus_init_ctrls(), the V4L2 control handler is initialized before allocating memory for ctx->ctrls. If this allocation fails, the function returns -ENOMEM without freeing the previously allocated handler resources, leading to a memory leak. Fix this by calling v4l2_ctrl_handler_free() on the ctx->ctrls allocation failure 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. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an Allwinner SoC or board with a Cedrus VPU available to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89897", "url": "https://ubuntu.com/security/CVE-2026-89897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: Serialize exclusive follower delivery cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89899", "url": "https://ubuntu.com/security/CVE-2026-89899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: disable delayed work before freeing an interrupted transmit cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89900", "url": "https://ubuntu.com/security/CVE-2026-89900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: core: Fix kmemleak due to missed rc_free_device() call The commit dccc0c3ddf8f (\"media: rc: fix race between unregister and urb/irq callbacks\") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm \"kworker/u16:1\", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89901", "url": "https://ubuntu.com/security/CVE-2026-89901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89902", "url": "https://ubuntu.com/security/CVE-2026-89902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Avoid preempt count underflow without probe LoongArch uses break 11 for the breakpoint placed after an instruction that Kprobes executes out of line. Since userspace can issue the same break instruction, do_bp() can reach kprobe_singlestep_handler() when there is no current probe. The handler actually returns false in this case, but it first calls preempt_enable_no_resched(). The corresponding preempt_disable() is done by kprobe_breakpoint_handler() on a real Kprobe hit, so it has not run here. As a result, an ordinary userspace breakpoint (code 11) underflows the current task's preempt count. This also makes in_interrupt() return true until the task schedules. One visible consequence is the socket cgroup attribution: cgroup_sk_alloc() treats the allocation as interrupt context and assigns the socket to the root cgroup. A socket opened from the SIGTRAP handler can then avoid a BPF_CGROUP_INET_SOCK_CREATE policy attached to the task's own cgroup. Return as soon as kprobe_running() reports no active probe. The same check has appeared in [PATCH v10 2/4] of the original LoongArch Kprobes series, but was dropped before the feature reached mainline.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89903", "url": "https://ubuntu.com/security/CVE-2026-89903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Do not save/restore percpu base register in rethook trampoline The rethook trampoline saves $r21 ($u0), the percpu base, into its frame at entry and restores it at exit. Inbetween rethook_trampoline_handler() may schedule via preempt_enable_notrace(). If the task migrates to another CPU, the frame's $r21 holds the old CPU's percpu base, and restoring it poisons $r21 on the new CPU. Until the next user->kernel transition heals $r21, all this_cpu_*() accesses (runqueues, RCU per-CPU data, timer tick programming, FPU ownership) hit the wrong CPU's percpu area. Under kretprobe-heavy preemptible load this can corrupt scheduler and timer state: scheduling-while-atomic splats, wrong-CPU RCU warnings, WARN_ON_ONCE(rq != this_rq()) in nohz_balance_exit_idle(), and CPUs parking in the idle loop with the constant timer never re-armed (hard lockup). Reproduces on a Loongson-3A6000 with kretprobes on VFS paths plus heavy file churn (OS install / unsquashfs). By convention $r21 always holds the current CPU's percpu base in kernel mode: SAVE_SOME() at exception entry reloads it only when coming from user mode, and RESTORE_SOME() restores it only when returning to user mode; the context-switch path never writes it. Therefore the live $r21 at trampoline exit is already correct, and nothing inbetween can change it legitimately (kernel C code cannot write a global register variable). The same flaw existed even in the pre-rethook kretprobe trampoline since v6.3; it was carried over when rethook replaced it. Drop both the save and the restore here. Drop the restore is enough to solve the issue, and drop the save is to keep the code tidy and no need to clear it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89908", "url": "https://ubuntu.com/security/CVE-2026-89908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the \"d -> f, e -> g\" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89909", "url": "https://ubuntu.com/security/CVE-2026-89909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Free init resources if kvm_init() fails kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init().", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:16:00 UTC" }, { "cve": "CVE-2026-89922", "url": "https://ubuntu.com/security/CVE-2026-89922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Take srcu when importing watchpoint data __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import.", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89923", "url": "https://ubuntu.com/security/CVE-2026-89923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT, so the charge also outlives the exiting process and pins dying memcgs. Fix by clearing the debug data on vCPU destruction. Calling it unconditionally is fine: struct kvm_vcpu is zero allocated, so for a vCPU that never enabled debugging the counters are 0 and the pointers NULL.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89924", "url": "https://ubuntu.com/security/CVE-2026-89924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_data memory areas.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89925", "url": "https://ubuntu.com/security/CVE-2026-89925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89926", "url": "https://ubuntu.com/security/CVE-2026-89926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: \twp_info->len = bp_data->len; \t[...] \tif (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) \t\treturn -EINVAL; \twp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fail and result in a WARN due to MAX_PAGE_ORDER.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89927", "url": "https://ubuntu.com/security/CVE-2026-89927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS). When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow. ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now)) This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter. Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years. kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle. Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2) rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0 rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. ( ... ) Call Trace: __run_hrtimer kernel/time/hrtimer.c:1773 [inline] __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline] __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline] sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697 RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194 Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36 RSP: 0018:ffffc900040a7320 EFLAGS: 00000206 RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900 RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001 RBP: ffffc900040a73b0 R08: ffffffff8fc3d0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89929", "url": "https://ubuntu.com/security/CVE-2026-89929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1) The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH). Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89930", "url": "https://ubuntu.com/security/CVE-2026-89930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on \"full\" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so that, after VM entry, the logical processor will not use any translations that were cached before the transition. The SDM is unclear about when the TLB flush should occur, and whether or not a failed VM entry would flush the TLB, so it is safer to always do the TLB flush in this case. More concretely, KVM also updates the last VPID L1 used for L2 in nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry ultimately fails. With the current code, KVM could miss a TLB flush if L1 changes L2's VPID, then does a failed VM entry followed by a successful one, as the failed VM entry would update last_vpid but not actually flush the TLB. Servicing local TLB flushes on failed VM entries makes sure that the TLB is always flushed when last_vpid is updated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89931", "url": "https://ubuntu.com/security/CVE-2026-89931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit Always check and clear KVM_REQ_GET_NESTED_STATE_PAGES when emulating a nested VM-Exit to ensure the request is cleared, even when KVM was built with CONFIG_KVM_HYPERV=n, as KVM subtly relies on the \"check\" to clear the flag and thus avoid double-mapping the vmcs12 pages, e.g. if KVM manages to bail from VM-Enter without processing the request, and then emulates VMLAUNCH or VMRESUME.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89932", "url": "https://ubuntu.com/security/CVE-2026-89932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM happens to reuse a VPID that has TLB entries on the physical CPU.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89933", "url": "https://ubuntu.com/security/CVE-2026-89933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in \"iio->name = id->name\" and crashes the kernel during probe. The IIO device name is always \"dps310\", so set it directly and drop the now-unused device-id lookup.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89934", "url": "https://ubuntu.com/security/CVE-2026-89934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: ltrf216a: fix runtime PM reference leak in error path ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference. This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read. Fix this by releasing the runtime PM reference before returning from the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89936", "url": "https://ubuntu.com/security/CVE-2026-89936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disable it on the transition from non-zero to zero, using the previously stored channel value to detect the edge. Balance the regulator on the I2C error path so the reference count stays consistent if the write fails.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89937", "url": "https://ubuntu.com/security/CVE-2026-89937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: sgp30: Handle IAQ thread creation failure kthread_run() can fail and return an error pointer, but sgp_probe() stores it and returns success, so the device is registered without its IAQ thread and sgp_remove() later passes the error pointer to kthread_stop(). Return the error from probe instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89938", "url": "https://ubuntu.com/security/CVE-2026-89938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig). The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work. Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free. Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work. free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270). This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89939", "url": "https://ubuntu.com/security/CVE-2026-89939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable atlas_buffer_postenable() acquires a runtime PM reference with pm_runtime_resume_and_get() but returns the result of atlas_set_interrupt() directly. If atlas_set_interrupt() fails, the runtime PM reference is leaked and the device can never autosuspend. Add pm_runtime_put_autosuspend() on the error path to balance the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89944", "url": "https://ubuntu.com/security/CVE-2026-89944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: hdac_hda: Fix hlink refcount leak on component registration failure hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference. Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89945", "url": "https://ubuntu.com/security/CVE-2026-89945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l34: drain threaded IRQ before runtime suspend cs35l34_runtime_suspend() currently switches the codec into regcache_cache_only(true), asserts reset low, and powers the device off without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l34_irq_thread() can still run after suspend has removed live hardware access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1..4 after cache_only has been enabled, ignores the regmap_read() failures, and can still execute the PROT_RELEASE_CTL release sequence or the BST fault power-down writes. Use disable_irq() before entering cache_only/reset-low/power-off so any in-flight threaded handler is drained and no new IRQ thread can run while the device is suspended. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only logs request_threaded_irq() failures and keeps going, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89946", "url": "https://ubuntu.com/security/CVE-2026-89946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l33: drain threaded IRQ before runtime suspend cs35l33_runtime_suspend() currently switches the codec into regcache_cache_only(true) and powers it down without first quiescing the threaded IRQ registered by devm_request_threaded_irq(). That leaves a window where cs35l33_irq_thread() can still run after suspend has closed off live register access. A running system can reach this during runtime PM while the driver still has critical fault IRQs unmasked. If the threaded handler runs in that window, it reads volatile INT_STATUS_1/2 after cache_only has been enabled, ignores the regmap_read() failures, and can still drive the AMP_SHORT_RLS, CAL_ERR_RLS, OTE_RLS, and OTW_RLS release paths. Use disable_irq() before entering cache_only/power-off so any in-flight threaded handler is drained and no new IRQ thread can run during the suspended state. Re-enable the IRQ only after runtime_resume() has restored live register access with regcache_sync(). Since probe only warns if devm_request_threaded_irq() fails, track whether the IRQ was actually installed before disabling or re-enabling it.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89948", "url": "https://ubuntu.com/security/CVE-2026-89948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89949", "url": "https://ubuntu.com/security/CVE-2026-89949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89950", "url": "https://ubuntu.com/security/CVE-2026-89950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: mcast: linearize skbuff for packet generation batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89951", "url": "https://ubuntu.com/security/CVE-2026-89951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches the local mesh interface. Refresh the receive device metadata from the current receive device before running the packet handlers. This keeps internally reinjected merged fragments consistent with the normal receive path after hard interface teardown.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89952", "url": "https://ubuntu.com/security/CVE-2026-89952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped diagnostics that identify the malformed ONFI section.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89953", "url": "https://ubuntu.com/security/CVE-2026-89953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. Free the bitmap after unregistering the dumper and flushing the pending workers, then clear the pointer and page count before a later attach can allocate fresh state. Clearing the pointer also keeps the module exit path from freeing the same bitmap a second time after a remove event.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89954", "url": "https://ubuntu.com/security/CVE-2026-89954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: afs: validate v2 image info bounds The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use. Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89955", "url": "https://ubuntu.com/security/CVE-2026-89955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix NULL deref in status_show() during queue probe When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference. Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released. As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89957", "url": "https://ubuntu.com/security/CVE-2026-89957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain removed The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of bitmap_andnot() to determine whether the guest APCB needs to be updated. However, bitmap_andnot() returns false when the resulting destination bitmap is empty. This means that if the only adapter, domain or control domain assigned to an mdev is removed from the host's AP configuration, the bit is correctly cleared from the shadow APCB, but bitmap_andnot() returns false because the result is an empty bitmap. Consequently, do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called, leaving the KVM guest with stale hardware access to the unplugged AP devices. Fix this by replacing the bitmap_andnot() return value check with bitmap_intersects() to determine whether the shadow APCB actually overlaps with the removal mask. If there is an intersection, call bitmap_andnot() solely for its side effect of clearing the bits, then unconditionally set do_hotplug to trigger the guest APCB update.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89958", "url": "https://ubuntu.com/security/CVE-2026-89958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL The ap_driver structure has two fields which are function pointers to callbacks: * .on_config_changed: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed. * .on_scan_complete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed. These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively. Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex. Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch. It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback functions. This ensures that matrix_mdev will not be removed via the vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock before removing the object; so, matrix_mdev will be available for the duration of the callback functions. 2. The matrix_dev->mdevs_lock mutex must be taken in order to access fields within the matrix_mdev structure 3. matrix_mdev->kvm->lock mutex must be taken before the matrix_dev->mdevs_lock to prevent a lockdep splat. 4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfio_ap_mdev_update_guest_apcb function. 5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89959", "url": "https://ubuntu.com/security/CVE-2026-89959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove The vfio_ap_config_remove function uses the bitmap_andnot function to clear bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmap_and function is used instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89960", "url": "https://ubuntu.com/security/CVE-2026-89960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM. Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition. The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read). The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock. Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89961", "url": "https://ubuntu.com/security/CVE-2026-89961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population vmemmap_populate_compound_pages() uses addr_pfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping. However, addr_pfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGE_SIZE step in addr covers PAGE_SIZE / sizeof(struct page) struct page slots. Since addr_pfn is compared against nr_pages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr. As a result, pfn_offset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position. Fix this by deriving addr_pfn directly from the current vmemmap address instead of carrying it as loop state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89962", "url": "https://ubuntu.com/security/CVE-2026-89962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec_file: Prevent kexec range truncation Sashiko AI review pointed out the following issue. The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways: 1. It compares the current range's start against the previous element (i-1) instead of the running target index (idx) 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'. This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges. For example, consider a sorted input array with three ranges: Range A (idx=0): [0x1000 - 0x9000] Range B (i=1): [0x2000 - 0x5000] (completely inside Range A) Range C (i=2): [0x6000 - 0x8000] (completely inside Range A) 1. When i=1 (Range B): ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE. The code executes: ranges[0].end = ranges[1].end, which erroneously shrinks Range A's end from 0x9000 down to 0x5000. 2. When i=2 (Range C): ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE. The code falls into the else block, creating a broken new range. As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes. Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89964", "url": "https://ubuntu.com/security/CVE-2026-89964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the \"eisa_irq_edge=\" kernel command line parameter (e.g. \"eisa_irq_edge=16,5\"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89965", "url": "https://ubuntu.com/security/CVE-2026-89965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89968", "url": "https://ubuntu.com/security/CVE-2026-89968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: reject unsolicited H2CData PDUs nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the \"list_add double add\" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89969", "url": "https://ubuntu.com/security/CVE-2026-89969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as \tqueue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89973", "url": "https://ubuntu.com/security/CVE-2026-89973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: check the data direction of a C2HData PDU nvme_tcp_handle_c2h_data() finds the request by command id and checks that it has a payload, but it does not check that the command asked for data to be read. A controller that answers a write command with C2HData therefore reaches nvme_tcp_recv_data(), where _copy_to_iter() hits WARN_ON_ONCE(i->data_source) and returns 0. The receive path turns that into -EFAULT and resets the controller. No data is copied, so this is not memory corruption. What a controller gets is a kernel warning it can raise at will, which is fatal on a host booted with panic_on_warn. The send path already knows the direction - it consults rq_data_dir() when it builds a command - and nvme_tcp_handle_r2t() checks the length and the offset of the request it names. The C2HData path does not check the direction at all. Reject a C2HData PDU whose command is not a read. Rejecting it fails the command and resets the controller, as the neighbouring check in this function does; what goes away is the warning. [ 6.885580] ------------[ cut here ]------------ [ 6.886457] WARNING: lib/iov_iter.c:193 at _copy_to_iter+0x289/0x1330, CPU#0: kworker/0:1H/71 [ 6.888137] CPU: 0 UID: 0 PID: 71 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.891165] Workqueue: nvme_tcp_wq nvme_tcp_io_work [ 6.891875] RIP: 0010:_copy_to_iter+0x289/0x1330 [ 6.903739] Call Trace: [ 6.904085] [ 6.909254] __skb_datagram_iter+0x433/0x820 [ 6.911026] skb_copy_datagram_iter+0x37/0x120 [ 6.911622] nvme_tcp_recv_skb+0xa07/0x4320 [ 6.913378] __tcp_read_sock+0x1ab/0x810 [ 6.915788] nvme_tcp_try_recv+0x152/0x1e0 [ 6.918222] nvme_tcp_io_work+0x1e4/0x6c0 [ 6.926906] [ 6.927226] ---[ end trace 0000000000000000 ]--- [ 6.927878] nvme nvme0: queue 1 failed to copy request 0x71 data [ 6.928709] nvme nvme0: receive failed: -14", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89975", "url": "https://ubuntu.com/security/CVE-2026-89975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: fix DHCHAP secret leak on parse failure nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation. If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation. This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace. With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing \tdhchap_secret=BAD or \tdhchap_ctrl_secret=BAD to /dev/nvme-fabrics deterministically takes the leaking parse path. Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89979", "url": "https://ubuntu.com/security/CVE-2026-89979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning). There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition. This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hw_params, hw_free and prepare operations call snd_pcm_buffer_access_lock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->buffer_accessing to a negative (if possible), so the PCM trigger just needs to check the runtime->buffer_accessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89980", "url": "https://ubuntu.com/security/CVE-2026-89980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: harmony: initialize locks before requesting IRQ snd_harmony_create() registers the IRQ before initializing h->lock and h->mixer_lock. A pending interrupt can invoke the handler while these locks are uninitialized. Initialize both locks before requesting the IRQ so the handler always sees valid lock state.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89982", "url": "https://ubuntu.com/security/CVE-2026-89982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89983", "url": "https://ubuntu.com/security/CVE-2026-89983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix debugfs UAF on adapter removal i2c_del_adapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the new_device sysfs attribute stays writable until device_del(). A write racing with removal still reaches i2c_device_probe(), which passes the freed adap->debugfs to debugfs_create_dir() as the new client's parent: BUG: KASAN: slab-use-after-free in lookup_noperm_common+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookup_noperm_common+0x407/0x430 simple_start_creating+0x9c/0x110 debugfs_start_creating+0xdb/0x1a0 debugfs_create_dir+0x24/0x350 i2c_device_probe+0x814/0xbf0 It's technically possible to create a client after i2c_deregister_clients has run. That client will never be unregistered and make wait_for_completion hang. Close the window by removing the new_device attribute at the start of i2c_del_adapter(). device_remove_file() will drain any clients left.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89984", "url": "https://ubuntu.com/security/CVE-2026-89984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Fix kernel address leakages in LBR stack Before Arch LBR gained CPL filtering support, a user-only branch stack could still contain kernel addresses. As a result, kernel branch records may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. For example, on Intel Tiger Lake, the following command can still report SYSRET/ERET entries with kernel-space from addresses: $ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \\ \t./perf bench syscall basic --loop 1000 | \\ \t./perf script -i - --fields brstack|tr ' ' '\\n'| \\ \tgrep -E '0x[89a-f][0-9a-f]{15}' Total time: 0.000 [sec] 0.219000 usecs/op 4,566,210 ops/sec [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.551 MB - ] 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/- 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/- 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/- 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/- The problem is that intel_pmu_lbr_filter() does not fully validate the privilege level of sampled entries. It filters some mismatches based on the branch type and the to address, but it does not reject entries whose from address violates the requested branch privilege filter. Fix this by extending software filtering to validate both from and to addresses against br_sel. Any LBR entry contains kernel address does not match the requested user filter is dropped. This prevents kernel addresses from appearing in user-only branch stacks.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-74268", "url": "https://ubuntu.com/security/CVE-2026-74268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: clear sock_ops cb flags before force-closing a child socket A child socket inherits the listener's bpf_sock_ops_cb_flags via sk_clone_lock(). If its setup fails in tcp_v4_syn_recv_sock() / tcp_v6_syn_recv_sock(), the child is freed through put_and_exit, where inet_csk_prepare_forced_close() drops the socket lock and tcp_done() runs without it. If BPF_SOCK_OPS_STATE_CB_FLAG was inherited, tcp_done() -> tcp_set_state() calls tcp_call_bpf(), which expects the lock and trips sock_owned_by_me(): WARNING: include/net/sock.h:1799 at tcp_set_state+0x433/0x550 RIP: 0010:tcp_set_state+0x433/0x550 include/net/sock.h:1799 Call Trace: tcp_done+0xba/0x250 net/ipv4/tcp.c:5095 tcp_v4_syn_recv_sock+0x850/0xa50 net/ipv4/tcp_ipv4.c:1787 tcp_check_req+0xf30/0x1360 net/ipv4/tcp_minisocks.c:926 tcp_v4_rcv+0x1047/0x1b50 net/ipv4/tcp_ipv4.c:2164 The child is freed before it is ever established, so it should run no sock_ops callback. Clear its cb flags in inet_csk_prepare_for_destroy_sock(), the common point for the IPv4, IPv6 and chtls forced-close paths and for the MPTCP ->syn_recv_sock() failure path (dispose_child), which reaches tcp_done() on a child that was never established too.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-89988", "url": "https://ubuntu.com/security/CVE-2026-89988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kprobes: Protect kprobe_blacklist with RCU __within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory. Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken. Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89989", "url": "https://ubuntu.com/security/CVE-2026-89989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89992", "url": "https://ubuntu.com/security/CVE-2026-89992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuidle: dt_idle_genpd: kfree() the original name allocation dt_idle_pd_alloc() kasprintf()s the full node path, then points pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s pd->name, which is no longer the start of the allocation. Copy the basename instead.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89993", "url": "https://ubuntu.com/security/CVE-2026-89993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89995", "url": "https://ubuntu.com/security/CVE-2026-89995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dma-direct: return struct page from dma_direct_alloc_from_pool() Commit 5b138c534fda (\"dma-direct: factor out a dma_direct_alloc_from_pool helper\") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89997", "url": "https://ubuntu.com/security/CVE-2026-89997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix resume-vs-remove race If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method. Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free. Fix this bug by refusing to resume if the device is being destroyed.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89998", "url": "https://ubuntu.com/security/CVE-2026-89998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix race when loading and unloading a table If the userspace calls two concurrent table load ioctls and one of them succeeds and the other fails, there is a race condition because dm_setup_md_queue walks &md->table_devices without any lock. If the walk races with dm_table_destroy -> free_devices -> dm_put_table_device, there is access to invalid memory. Fix this race by extending the lock over the list walk.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89999", "url": "https://ubuntu.com/security/CVE-2026-89999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: validate report length in wacom_intuos_pro2_bt_irq wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: \twacom_intuos_pro2_bt_pen(wacom); \tif (type == INTUOSP2_BT || type == INTUOSP2S_BT) { \t\twacom_intuos_pro2_bt_touch(wacom); \t\twacom_intuos_pro2_bt_pad(wacom); \t\twacom_intuos_pro2_bt_battery(wacom); \t} else { \t\twacom_intuos_gen3_bt_pad(wacom); \t\twacom_intuos_gen3_bt_battery(wacom); \t} Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] \t(the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT (\"gen3\"): wacom_intuos_gen3_bt_battery() reads data[45], \tso the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 (\"HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq\") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90000", "url": "https://ubuntu.com/security/CVE-2026-90000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: rmi: fix OOB access with undersized RMI reports The hid-rmi driver sizes its writeReport/readReport buffer purely from the report descriptor supplied by the device, with no minimum bound: \tdata->input_report_size = hid_report_len(input_report); \tdata->output_report_size = hid_report_len(output_report); \talloc_size = data->output_report_size + data->input_report_size; \tdata->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); \tdata->readReport = data->writeReport + data->output_report_size; but then reads and writes fixed offsets into it. A device declaring a 1-byte output and a 1-byte input report makes hid_report_len() return 2 for each, so alloc_size is 4, while rmi_set_page() -- reached unconditionally at probe time through rmi_input_configured() -- stores writeReport[4] and rmi_hid_read_block() stores writeReport[0..5]. Since readReport lives at writeReport + output_report_size, those stores also corrupt the window the next reply is parsed out of. The read path is worse: the copy length comes from readReport[1], which the device fills in and can be up to 255, and the copy starts at &readReport[2] with no regard for input_report_size, so it runs past the end of the allocation into adjacent slab objects. This does not even need a lying device -- rmi_f01_probe() issues a fixed 21-byte register read, so any device declaring an input report smaller than 23 bytes reads out of bounds even when it answers truthfully. Those bytes become the register values the RMI core acts on: rmi_f01_probe() prints them to the kernel log as the product id and exports them through the mode 0444 sysfs attribute of the same name, and rmi_driver_set_irq_bits() sends them back to the device as the interrupt mask, so an undersized report descriptor leaks heap contents both to unprivileged userspace and to the device itself. The write path has no bound either: rmi_hid_write_block() copies an unbounded len to &writeReport[4], and the largest caller a device can drive at probe time is rmi_driver_set_irq_bits(), whose length is derived from the interrupt source counts the device declares in its Page Description Table. Finally, the read loop cannot terminate on a zero-length reply: such a reply copies nothing and advances neither bytes_read nor bytes_needed, and because a reply did arrive the one second wait_event_timeout() does not fire either, so a device answering 0 forever keeps the loop running inside the probe worker with page_mutex held. khungtaskd does not notice, because every reply wakes the task. Reject reports too small for what the driver builds -- 6 output bytes for the write reports and 3 input bytes for the read handshake -- at probe time, clamp the write and the read copy to the report sizes the device declared, and treat a zero-length reply as an error. A device refused this way is started as an ordinary HID device, like one that does not carry the RMI report ids at all. RMI_DEVICE must not be left set in device_flags on that path, because rmi_input_configured() would then run the RMI setup and reach rmi_set_page(), which writes the writeReport buffer the refusal just skipped allocating. The bit can arrive set: rmi_probe() copies id->driver_data into device_flags before the report checks, and a bind through the new_id sysfs attribute can supply driver_data with RMI_DEVICE (BIT(0)) set. Strip the bit where driver_data is copied, so RMI_DEVICE keeps meaning exactly \"this probe validated the reports\"; the three jumps to start that predate this patch are covered as well. The error path also clears RMI_READ_DATA_PENDING on its way out, because that flag is what the wait at the top of the loop tests: leaving it set would make every later wait_event_timeout() return immediately on the stale reply and kill the read path for the rest of the device's life. Clamping does not regress working hardware: the read loop already handles ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90003", "url": "https://ubuntu.com/security/CVE-2026-90003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent rcuwait use-after-free during requeue PI On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up(). The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows: waiter requeue task ------ ------------ futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter * futex_requeue_pi_wakeup_sync() Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete() cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event() if (atomic_read(&q->requeue_state) != Q_REQUEUE_PI_WAIT) break /* no schedule() */ /* q.pi_state->owner == current */ futex_private_hash_put() /* return from syscall */ rcuwait_wake_up(&q->requeue_wait) /* q is gone */ futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake. To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q->task before futex_requeue_pi_complete() and wakes the waiter via wake_up_state(). This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected. [bigeasy: Updated comment and commit message]", "cve_priority": "high", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90007", "url": "https://ubuntu.com/security/CVE-2026-90007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Use rollback index when freeing MSI-X vectors pm8001_request_msix() unwinds previously registered handlers with free_irq() when request_irq() fails. The rollback loop uses the failing index i for every iteration instead of the already registered vector index j. That passes the wrong IRQ/dev_id pair to free_irq() and leaves the earlier handlers installed. Use j for both pci_irq_vector() and the matching irq_vector entry in the rollback loop.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90011", "url": "https://ubuntu.com/security/CVE-2026-90011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where \tpadding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89793", "url": "https://ubuntu.com/security/CVE-2026-89793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: clear VM_MAYWRITE on read-only ublk char device mmap ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.", "cve_priority": "medium", "cve_public_date": "2026-09-16 10:16:00 UTC" }, { "cve": "CVE-2026-90017", "url": "https://ubuntu.com/security/CVE-2026-90017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: \tconst u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); \t... \tc = frame_body[0]; \t... \ta = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90018", "url": "https://ubuntu.com/security/CVE-2026-90018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: \tif (attr_ptr + 4 > wps_ie + wps_ielen) \t\tbreak; \tu16 attr_id = get_unaligned_be16(attr_ptr); \tu16 attr_data_len = get_unaligned_be16(attr_ptr + 2); \tu16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: \tmemcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack \"u8 sr\"/\"u8 selected_registrar\" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The \"attr_ptr + 4 > wps_ie + wps_ielen\" header check above was added by commit 1463ca3ec6601 (\"staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()\"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90019", "url": "https://ubuntu.com/security/CVE-2026-90019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90020", "url": "https://ubuntu.com/security/CVE-2026-90020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90021", "url": "https://ubuntu.com/security/CVE-2026-90021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90022", "url": "https://ubuntu.com/security/CVE-2026-90022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi2: fix use-after-free in string attribute show path f_midi2_opts_str_show() takes the string lock internally, but its callers dereference the opts->info. pointer before calling it, outside the lock. This races with f_midi2_opts_str_store(), which frees the old string under opts->lock when the attribute is written concurrently, the show path can read a pointer that gets freed before the lock inside str_show() is even taken. Change f_midi2_opts_str_show() to take a pointer to the string field, matching the existing pattern in f_midi2_opts_str_store(), and dereference it only after the lock is held. Update all three callers (iface_name, block name, and the EP string option macro) accordingly.", "cve_priority": "low", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90024", "url": "https://ubuntu.com/security/CVE-2026-90024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90025", "url": "https://ubuntu.com/security/CVE-2026-90025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix OOB altmode array index The UCSI displayport driver indexes the connector's port altmode array with the GET_CURRENT_CAM response after checking it is not 0xff. The port altmode array is UCSI_MAX_ALTMODES elements long. If the PPM returns an invalid GET_CURRENT_CAM response above UCSI_MAX_ALTMODES and not equal to 0xff, the kernel may crash with an array index OOB error. Update the UCSI displayport driver to verify the current cam is less than UCSI_MAX_ALTMODES before accessing the port altmode array.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90026", "url": "https://ubuntu.com/security/CVE-2026-90026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: cancel reset_work on stop pdphy_stop() disables IRQs but leaves reset_work pending. If the IRQ handler schedules it just before disable_irq(), the work runs after remove() frees the struct via devm. Call cancel_work_sync() after disabling IRQs to close the window. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90031", "url": "https://ubuntu.com/security/CVE-2026-90031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90032", "url": "https://ubuntu.com/security/CVE-2026-90032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: usbtv: keep device alive while ALSA card exists The ALSA PCM callbacks store the driver state in pcm->private_data. An open PCM file can outlive USB disconnect because usbtv_audio_free() uses snd_card_free_when_closed(). The disconnect path can then drop the V4L2 device reference and free struct usbtv before ALSA releases the substream, so a later close dereferences freed memory in snd_usbtv_pcm_close(). Take a V4L2 device reference for the ALSA card and drop it from the card private_free callback. This keeps struct usbtv valid until ALSA has closed the remaining files and freed the card.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90033", "url": "https://ubuntu.com/security/CVE-2026-90033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90034", "url": "https://ubuntu.com/security/CVE-2026-90034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-90035", "url": "https://ubuntu.com/security/CVE-2026-90035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2026-89603", "url": "https://ubuntu.com/security/CVE-2026-89603", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89595", "url": "https://ubuntu.com/security/CVE-2026-89595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix stale object mask after concurrent mark updates When a mark gets a new event bit, fanotify and inotify may avoid recalculating the object mask if the cached aggregate already contains that bit. This is racy with a recalculation triggered by a concurrent update to another mark on the same connector. The concurrent scan can read the mark before the new bit is added, while the updater reads the old aggregate before that scan publishes its result. The updater then skips recalculation and the scan publishes a mask without the bit, leaving the object mask stale after both updates complete. This can be reproduced with two fanotify groups watching the same inode: one thread removes FAN_MODIFY from one existing mark while another thread adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return, writes can fail to produce FAN_MODIFY for the group whose mark now contains the bit. This was reproduced on an unmodified v6.12.95 kernel. The equivalent inotify interleaving loses IN_MODIFY events. For normal fanotify additions, recalculate whenever the raw mark mask changes. The normal mask is not cleared asynchronously, so an unchanged addition cannot introduce missing interest. Always recalculate ignore-mask updates because FS_MODIFY handling may clear the ignore mask without taking mark->lock, making snapshot comparisons unreliable. Always recalculate after updating an existing inotify watch. Its replace path temporarily sets mark->mask to zero, so a concurrent scan can observe zero even when the old and final masks are equal. Assigning the replacement mask directly would avoid the transient zero, but existing-watch updates are infrequent, so unconditional recalculation is simpler.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80933", "url": "https://ubuntu.com/security/CVE-2026-80933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: validate default EEPROM firmware size The default EEPROM firmware is parsed and copied as a full EEPROM without checking its length. A truncated file can make the driver read beyond the firmware buffer during variant validation or the fallback copy. Reject files shorter than MT7996_EEPROM_SIZE before parsing or copying the firmware.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-53250", "url": "https://ubuntu.com/security/CVE-2026-53250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata() The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path. Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment. Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-89560", "url": "https://ubuntu.com/security/CVE-2026-89560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation Whiteout objects are used in the upper layer of an OverlayFS to indicate that the file with this name does not exist in the unified view, even if it is present in one of the lower layer file systems. For the userspace implementations of OverlayFS (fuse-overlayfs), whiteout objects can be created from userspace as well: * mknod(2) with S_IFCHR and makedev(0, 0) * renameat2(2) with RENAME_WHITEOUT, creating the whiteout in the old place of the moved file. This commit guards whiteout creation in both of these cases with LANDLOCK_ACCESS_FS_MAKE_REG. Whiteout objects are *not* considered character devices and are not bound to a driver. LANDLOCK_ACCESS_FS_MAKE_REG describes the same permission class as a whiteout object: creating one is the only S_IFCHR creation that the VFS exempts from CAP_MKNOD, so it is as unprivileged as creating a regular file, while LANDLOCK_ACCESS_FS_MAKE_CHAR and LANDLOCK_ACCESS_FS_MAKE_BLOCK keep meaning the creation of devices that expose a kernel interface [1]. For the mknod(2) case, introduce a Landlock erratum. The creation of whiteout objects through mknod(2) was previously guarded using LANDLOCK_ACCESS_FS_MAKE_CHAR, and it is now guarded using LANDLOCK_ACCESS_FS_MAKE_REG. For the renameat2(2) case, fix a bug: Before this commit, renameat2(2) with RENAME_WHITEOUT would create a directory entry even when all LANDLOCK_ACCESS_FS_MAKE_* rights were denied. This does not affect normal renames within layered OverlayFS mounts: When doing a regular rename() on a mounted fuse-overlayfs, it is the fuse-overlayfs daemon that exercises renameat2() with RENAME_WHITEOUT, and only the Landlock domain of that daemon is checked there. Depends-on: 49c9e09d9610 (\"landlock: Fix handling of disconnected directories\") Depends-on: fe72ce6710cb (\"landlock: Add errata documentation section\") [mic: Record why LANDLOCK_ACCESS_FS_MAKE_REG is the matching right, and add link(2) to the user doc]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89488", "url": "https://ubuntu.com/security/CVE-2026-89488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix CT limit teardown use-after-free Packet processing uses CT limit state under RCU, while netns teardown frees that state under ovs_mutex. The CT limit pointer was neither removed from readers nor protected by a grace period, allowing packet processing to dereference the freed state. An unprivileged user can trigger this bug from a user and network namespace, causing a slab-use-after-free in ovs_ct_execute() when the netns is torn down. Publish the CT limit pointer through RCU, remove it before teardown, and wait for readers before freeing its contents. Keep ovs_mutex around individual CT limit updates, and use the RCU read-side lock while GET traverses the RCU-protected limit lists. Netns teardown detaches the RCU-protected CT limit state in the pernet .pre_exit callback while holding ovs_mutex. The pernet core guarantees an RCU grace period between the .pre_exit and .exit callbacks, so the .exit callback completes the teardown without adding any extra synchronization. The netlink command handlers do not need NULL checks because the userspace netlink socket holds an active reference to its network namespace while a request is processed. The per-netns exit path therefore cannot run concurrently with SET, DEL, or GET for that socket's namespace.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-90049", "url": "https://ubuntu.com/security/CVE-2026-90049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by dropping it here. On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on this error: do_execute_actions() ignores output_userspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack still handles. That flag is what makes esp_input() call skb_cow_data() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately. Leave error reporting to the callers.", "cve_priority": "medium", "cve_public_date": "2026-09-16 11:17:00 UTC" }, { "cve": "CVE-2024-56639", "url": "https://ubuntu.com/security/CVE-2024-56639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: must allocate more bytes for RedBox support Blamed commit forgot to change hsr_init_skb() to allocate larger skb for RedBox case. Indeed, send_hsr_supervision_frame() will add two additional components (struct hsr_sup_tlv and struct hsr_sup_payload) syzbot reported the following crash: skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206 Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_over_panic net/core/skbuff.c:211 [inline] skb_put+0x174/0x1b0 net/core/skbuff.c:2617 send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342 hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436 call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794 expire_timers kernel/time/timer.c:1845 [inline] __run_timers+0x6e8/0x930 kernel/time/timer.c:2419 __run_timer_base kernel/time/timer.c:2430 [inline] __run_timer_base kernel/time/timer.c:2423 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2439 run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449 handle_softirqs+0x213/0x8f0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0xbb/0x120 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 ", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2026-23201", "url": "https://ubuntu.com/security/CVE-2026-23201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix oops due to invalid pointer for kfree() in parse_longname() This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running `ls /mnt/my_ceph/.snap`. The variable str is guarded by __free(kfree), but advanced by one for skipping the initial '_' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer. Steps to reproduce: 1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase) 2. Add cephfs mount to fstab $ echo \"samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0\" >> /etc/fstab 3. Reboot the system $ systemctl reboot 4. Check if it's really mounted $ mount | grep stuff 5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap Now ls hangs forever and the kernel log shows the oops.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-37833", "url": "https://ubuntu.com/security/CVE-2025-37833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error.", "cve_priority": "low", "cve_public_date": "2025-05-08 07:15:00 UTC" }, { "cve": "CVE-2026-80928", "url": "https://ubuntu.com/security/CVE-2026-80928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix cred UAF in smack_file_send_sigiotask() When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80930", "url": "https://ubuntu.com/security/CVE-2026-80930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the interrupt handler to report a status change. If the wait times out, or is interrupted before the handler runs, the function returns without balancing the enable_irq() call. Disable the IRQ before leaving the failed wait path. Also preserve an interrupted wait's original error code instead of converting it to -ETIMEDOUT inside the helper.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80931", "url": "https://ubuntu.com/security/CVE-2026-80931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: ds28e17: reject an oversize length on an I2C block read w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the device. The downstream slave puts a length byte in buf[0]. The driver then reads that many bytes into buf[1] with w1_f19_i2c_read(). buf[0] is controlled by the device and can be 0 to 255. w1_f19_i2c_read() only rejects a zero count. The caller buffer is I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read run past it, up to about 222 bytes out of bounds. The SMBus core does check buf[0] against I2C_SMBUS_BLOCK_MAX. That check runs after master_xfer returns. By then the write is already done. i2c-algo-bit rejects an oversize length before it copies, and returns -EPROTO. Reject a length above I2C_SMBUS_BLOCK_MAX at both RECV_LEN sites, the same way i2c-algo-bit does.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80932", "url": "https://ubuntu.com/security/CVE-2026-80932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80938", "url": "https://ubuntu.com/security/CVE-2026-80938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80941", "url": "https://ubuntu.com/security/CVE-2026-80941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb() The skb passed to the rtw_hci_tx_write() is expected to be freed when the function fails, but the error path in rtw_txq_push_skb() does not free the skb before returning. This can lead to a memory leak in rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80944", "url": "https://ubuntu.com/security/CVE-2026-80944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> \"bF878X,\\0\" which is a fragment of the VERSION_EXT firmware string exposed as debugfs \"verext\": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> \"153.7\\0$\" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:18:00 UTC" }, { "cve": "CVE-2026-80834", "url": "https://ubuntu.com/security/CVE-2026-80834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ce support which is one of the only remaining ones. Note that the sun8i-ce support for hwrng remains in place. That is the interface that actually matters. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. There's no point in fixing this separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80833", "url": "https://ubuntu.com/security/CVE-2026-80833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss - Remove crypto_rng interface Since the crypto_rng interface for hardware PRNGs is unused and is redundant with hwrng and the actual Linux RNG, it's being phased out. Most drivers for it were already removed. Go ahead and remove the sun8i-ss support which is one of the only remaining ones. As usual for crypto_rng, this driver was also buggy: its ->generate() function had a use-after-free vulnerability due to using wait_for_completion_interruptible_timeout() without handling shutting down the DMA operation if a signal is sent. Also, it had a buffer overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'. There's no point in fixing these bugs separately only to remove the code anyway, so this commit is marked with Fixes and Cc stable.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80947", "url": "https://ubuntu.com/security/CVE-2026-80947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop rtl8xxxu arms rx_urb_wq from the RX completion path: rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which queues it on rx_urb_pending_list and, once the list grows past RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq. The worker rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(), which anchors it on rx_anchor and dereferences priv->udev. rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog, update_beacon_work) but never cancels rx_urb_wq, so a worker armed during the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect. There are two teardown races to close: * rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock but called schedule_work() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedule_work() after rtl8xxxu_stop() had set shutdown and cancel_work_sync() had already returned, arming the worker to run after the teardown. Move schedule_work() under the same !shutdown branch so the arming decision is atomic with the shutdown check. * rtl8xxxu_rx_urb_work() anchors every URB it drained back onto rx_anchor through rtl8xxxu_submit_rx_urb(). A worker still running when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a URB that escaped the kill. In rtl8xxxu_stop(), call cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is drained first. After priv->shutdown is set under rx_urb_lock, completions can no longer queue rx_urb_wq. cancel_work_sync() then drains the last queued or running worker, and the following usb_kill_anchored_urbs() kills the URBs it may have submitted. rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw() guarantees .stop() runs for a live interface before ieee80211_free_hw() frees priv. The probe error path needs no cancel: rx_urb_wq is INIT_WORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211_register_hw() succeeds. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80949", "url": "https://ubuntu.com/security/CVE-2026-80949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control() The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. [arend: rework as suggested by Johannes]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80951", "url": "https://ubuntu.com/security/CVE-2026-80951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: bound IBI payload to the requested max_payload_len svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80952", "url": "https://ubuntu.com/security/CVE-2026-80952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix info leak and UAF in device unregister path i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind. Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80963", "url": "https://ubuntu.com/security/CVE-2026-80963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stats: fix a crash if allocation of per-cpu data fails If \"dm_kvzalloc(percpu_alloc_size, cpu_to_node(cpu))\" fails, the code jumps to the \"out\" label and calls dm_stat_free. dm_stat_free does \"for_each_possible_cpu(cpu) { dm_kvfree(s->stat_percpu[cpu][0].histogram, s->histogram_alloc_size);\", which crashes with NULL pointer dereference if s->stat_percpu[cpu] is NULL. This commit fixes the bug by testing s->stat_percpu[cpu] for NULL before using it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89771", "url": "https://ubuntu.com/security/CVE-2026-89771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix subbuf resize race with ring buffer readers trace_buffer subbuf_size is read lockless in ring_buffer_read_page() and ring_buffer_read_start(), while it can simultaneously be resized with ring_buffer_subbuf_order_set(). Instead of trace_buffer::subbuf_size, use bpage::order in ring_buffer_read_start() and ring_buffer_read_page(). In ring_buffer_read_start(), even with resize_disabled, there is still a possibility of a race with a buffer modification. Hold the trace_buffer mutex to synchronise with any pending ring buffer order modification. trace_buffer::subbuf_size is now actually useless, remove it. Also, create accessors rb_subbuf_capacity() and rb_page_capacity() which return the actual size available for storing events, while rb_subbuf_size() returns the actual subbuf page-size.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-80964", "url": "https://ubuntu.com/security/CVE-2026-80964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80965", "url": "https://ubuntu.com/security/CVE-2026-80965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80966", "url": "https://ubuntu.com/security/CVE-2026-80966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80967", "url": "https://ubuntu.com/security/CVE-2026-80967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80968", "url": "https://ubuntu.com/security/CVE-2026-80968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as \"none\" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80969", "url": "https://ubuntu.com/security/CVE-2026-80969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80971", "url": "https://ubuntu.com/security/CVE-2026-80971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: \tusb_kill_urb(bcd2k->midi_out_urb); \tusb_kill_urb(bcd2k->midi_in_urb); \tusb_free_urb(bcd2k->midi_out_urb); \tusb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: \tbcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; \t... \tret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80972", "url": "https://ubuntu.com/security/CVE-2026-80972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80973", "url": "https://ubuntu.com/security/CVE-2026-80973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: \tif (!urb->status) { \t\tif (rt->receiver_buffer[0] == 0x10) /* midi in event */ \t\t\tif (midi_rt) \t\t\t\tmidi_rt->in_received(midi_rt, \t\t\t\t\t\trt->receiver_buffer + 2, \t\t\t\t\t\trt->receiver_buffer[1]); \t} receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80974", "url": "https://ubuntu.com/security/CVE-2026-80974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix potential memory leaks during remove The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree().", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80976", "url": "https://ubuntu.com/security/CVE-2026-80976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet. The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6_protocol_deliver_rcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports: BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu ip6_protocol_deliver_rcu+0x1118/0x1450 ip6_input_finish+0x11b/0x240 seg6_local_input_core+0xed/0x2e0 lwtunnel_input+0x1e9/0x4e0 ipv6_rthdr_rcv+0x525f/0x6c50 ip6_protocol_deliver_rcu+0xcb7/0x1450 Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field. Use IP6CB(skb)->iif rather than skb->skb_iif because VRF processing can replace skb_iif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKB_L3SLAVE for the same reason.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80977", "url": "https://ubuntu.com/security/CVE-2026-80977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while do_execute_actions() keeps forwarding the original, and skb_clone() does not privatise the frags here -- skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN. A flow miss on the clone then strips the marker from the packet still being forwarded, and a later local ESP delivery decrypts in place over frags it does not own privately. Skip it for a cloned skb. Nothing is lost: skb_release_data() clears the zerocopy state once the last reference to the shared data goes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80978", "url": "https://ubuntu.com/security/CVE-2026-80978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a packet needs more headroom. A nonsensical stacked configuration can therefore incur an extra reallocation, but it cannot publish an unbounded reservation to upper layers.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80979", "url": "https://ubuntu.com/security/CVE-2026-80979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: unregister the connection before draining the rx tasklet smc_conn_free() calls smc_ism_unset_conn() only while the link group is still on its device list, and never sets conn->killed. smc_lgr_terminate_sched() unlinks the group immediately and defers killing its connections to a work item, so a connection freed in that window keeps its smcd->conn[] slot with both gates in smcd_handle_irq() open, and the device can re-arm the receive tasklet after tasklet_kill() has returned. On the DMB-nocopy path the ghost send buffer is freed right after that drain, so the re-armed tasklet dereferences it. Unregister unconditionally and drain before the detach at both teardown sites, mirroring rmb_desc, which smc_buf_unuse() releases after the drain. Clear conn->sndbuf_desc before freeing it as well, so a reader that samples the pointer cannot get one that is already freed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80982", "url": "https://ubuntu.com/security/CVE-2026-80982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_reg_err path smcr_buf_unuse() frees the descriptor outright, so this is a use-after-free. Take the socket lock first and test conn->freed instead. smc_conn_free() sets that flag before releasing anything, and every caller holds the socket lock. The two paths exclude each other: either the pipe release runs first with everything valid, or it sees the flag and skips the update.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80983", "url": "https://ubuntu.com/security/CVE-2026-80983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The second error exit is not affected, because sock_put() has already run by then. A leaked sk_refcnt means the smc_sock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down. smc_cdc_get_free_slot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smc_switch_conns() run in the first place. Restructure so there is a single sock_put() covering both outcomes, instead of adding a second one to the error path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80984", "url": "https://ubuntu.com/security/CVE-2026-80984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not dereference an unset send buffer on the SMC-D teardown path smc_close_stream_wait() calls smc_tx_prepared_sends() from inside its sk_wait_event() condition, and sk_wait_event() evaluates that condition once with the socket lock released. smcd_buf_detach() clears conn->sndbuf_desc from smc_conn_kill() under lock_sock(), so a link group terminating while a socket waits there leaves the helper dereferencing NULL, faulting out of close(). SIOCOUTQ reads the field by hand, and smc_close_cancel_work() drops the lock across two cancel_*_sync() calls. Sample the pointer once in the helper, report nothing prepared while it is unset, and bound the ioctl the same way. The receive tasklet dereferences the field directly in smc_cdc_msg_recv_action(), not through this helper; 1/2 is what keeps it from running that late.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80987", "url": "https://ubuntu.com/security/CVE-2026-80987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80988", "url": "https://ubuntu.com/security/CVE-2026-80988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 (\"ntb: Drop packets when qp link is down\") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller. With the preceding patch, ntb_netdev frees the skb on non-retryable enqueue failures and returns NETDEV_TX_OK, so a packet racing with link-down is dropped without leaking or entering a busy retry loop.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80989", "url": "https://ubuntu.com/security/CVE-2026-80989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Mark the connection down when bringing it up fails Every failure path in tbnet_connected_work() undoes its own work and returns without clearing login_sent, so the connection still looks established. The next tbnet_tear_down() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a dev_WARN() and fatal under panic_on_warn, and it releases net->remote_transmit_path even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is still using. Clear login_sent on those paths. That is enough for tbnet_tear_down() to leave the unwound state alone, and login_received has to stay set: it records that the peer has logged in and carries the transmit path it gave us, which nothing on this side can make the peer send again. Two things change beyond keeping the teardown out of the way: the logout request in that block is no longer sent, and the peer's next login request now re-queues our login work rather than connected_work, giving the connection a fresh login instead of a retry on stale state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80990", "url": "https://ubuntu.com/security/CVE-2026-80990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Release the Rx HopID that was handed out on mismatch tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it. Release the id when it is not the one we asked for, the same way the error unwind at the end of the function releases the expected one.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80991", "url": "https://ubuntu.com/security/CVE-2026-80991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: serialize PTP clock teardown ravb_ptp_interrupt() can race with ravb_ptp_stop() and pass the clock to ptp_clock_event() while ptp_clock_unregister() is freeing it. This can lead to a use-after-free. Use READ_ONCE() and WRITE_ONCE() for lockless access to the clock pointer. Atomically detach it with xchg() before disabling PTP interrupts, then synchronize all IRQs which can invoke ravb_ptp_interrupt() before unregistering the detached clock. A handler which read the old pointer completes before the clock is unregistered, while later handlers read NULL and skip the event.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80992", "url": "https://ubuntu.com/security/CVE-2026-80992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ravb: avoid dereferencing an invalid PTP clock The PTP clock is unavailable before the first open, so querying its index can dereference a NULL pointer. Registration failures can also leave an error pointer in priv->ptp.clock. Cache the PHC index separately and report -1 while no clock is registered. Normalize registration errors to NULL and preserve the static timestamping capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80994", "url": "https://ubuntu.com/security/CVE-2026-80994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix flow mask use-after-free on flow deletion The commit in the Fixes tag below made so flow->mask free is scheduled via RCU right after it is removed from the flow table. The pointer stays in the flow structure and it can be accessible while in the same RCU critical section. This is done to avoid requiring ovs_mutex for the ovs_flow_free(). However, while removing the flow during processing of CMD_DEL, we do not take RCU read lock before the removal, and ovs_flow_cmd_fill_info() uses the flow->mask pointer afterwards. The RCU read lock is taken, but it's already late at that point. The comment on that line acknowledges that the lock is cosmetic and doesn't serve a real purpose. This leads to use-after-free if the RCU grace period passes between removal and the filling. It is a short race window, but it is there and can lead to a real crash in case memory allocation for the info takes a bit longer: BUG: KASAN: slab-use-after-free in __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 BUG: KASAN: slab-use-after-free in ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 Read of size 4 at addr ffff88801ee89970 by task ovs_flow_del_ec/9487 Call Trace: __ovs_nla_put_key net/openvswitch/flow_netlink.c:1996 ovs_nla_put_key+0x2463/0x2e30 net/openvswitch/flow_netlink.c:2250 ovs_flow_cmd_fill_info+0x420/0x9c0 net/openvswitch/datapath.c:930 ovs_flow_cmd_del+0x53a/0x970 net/openvswitch/datapath.c:1467 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Allocated by task 9487: mask_alloc net/openvswitch/flow_table.c:967 flow_mask_insert net/openvswitch/flow_table.c:1012 ovs_flow_tbl_insert+0xea2/0x1a90 net/openvswitch/flow_table.c:1084 ovs_flow_cmd_new+0x7e3/0xd90 net/openvswitch/datapath.c:1086 ... netlink_rcv_skb+0x156/0x420 net/netlink/af_netlink.c:2556 Freed by task 9485: rcu_free_sheaf+0x1e/0x100 mm/slub.c:5978 rcu_do_batch kernel/rcu/tree.c:2645 rcu_core+0x59c/0x10c0 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9a0 kernel/softirq.c:622 ... instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 ovs_flow_tbl_remove() must be called after the ovs_flow_cmd_fill_info() to avoid this race. This also helps with cleaning up the forced cast and the cosmetic RCU read lock. Before the commit in the Fixes tag the order did not matter as long as the flow object itself was not freed. A wider RCU critical section could be another option, but we have a GFP_KERNEL allocation in the way. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-32042.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80996", "url": "https://ubuntu.com/security/CVE-2026-80996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: l2tp: do not propagate multicast notification errors The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it. For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects. Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80999", "url": "https://ubuntu.com/security/CVE-2026-80999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89439", "url": "https://ubuntu.com/security/CVE-2026-89439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Add a NULL check for sst_inst[] To be consistent with other places, add a NULL check for failed socket loading by checking isst_common.sst_inst[].", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81000", "url": "https://ubuntu.com/security/CVE-2026-81000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81001", "url": "https://ubuntu.com/security/CVE-2026-81001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: fix use-after-free in sl_sync() slip_devs[] stores bare net_device pointers and takes no reference on them. sl_sync() and sl_alloc() walk that table from slip_open() under rtnl_lock(), while an entry is dropped by sl_free_netdev(), which sl_setup() installs as dev->priv_destructor. priv_destructor is called from netdev_run_todo(), which deliberately runs with the RTNL semaphore released so that it can sleep while waiting for the device refcount to drop: \t/* Snapshot list, allow later requests */ \tlist_replace_init(&net_todo_list, &list); \t__rtnl_unlock(); \t... \t\tif (dev->priv_destructor) \t\t\tdev->priv_destructor(dev);\t/* slip_devs[i] = NULL */ \t\tif (dev->needs_free_netdev) \t\t\tfree_netdev(dev); \t\t... \t\t/* Free network device */ \t\tkobject_put(&dev->dev.kobj); So rtnl_lock() does not serialise slip_open() against the teardown at all. sl_sync() can load slip_devs[i] while the entry is still published and dereference it after netdev_run_todo() has run the destructor and released the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) /* dev is freed */ sl = netdev_priv(dev) if (sl->tty || sl->leased) /* use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860 Commit e58c19124189 (\"slip: Fix use-after-free Read in slip_open\") fixed a different source of stale entries - a device left in slip_devs[] after slip_open() freed it on the registration error path - and does not address this race, which is why the report survives it. Drop the entry from ndo_uninit instead. unregister_netdevice() calls ndo_uninit under RTNL, before the device is queued to netdev_run_todo(), so an entry that sl_sync() can still see while holding RTNL belongs to a device that cannot be freed until RTNL is dropped. sl_free_netdev() stays only for the slip_open() error path, where register_netdevice() may have failed before ndo_init and ndo_uninit is then not called either. Both running for the same device is harmless: the ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81002", "url": "https://ubuntu.com/security/CVE-2026-81002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: fix zero-copy frame layout xdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page and advertises PAGE_SIZE as its frame size. It allows the copied frame to occupy the page tail needed by skb_shared_info and records zero headroom even when metadata separates the frame header from packet data. An AF_XDP zero-copy packet redirected through cpumap can therefore make the skb overlap skb_shared_info or place it beyond the allocated page. Limit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the metadata length in frame headroom. Redirect callers already handle a NULL conversion result. BUG: KASAN: slab-out-of-bounds in skb_gro_receive Write of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146 Call Trace: skb_gro_receive (net/core/gro.c:174) udp_gro_receive (net/ipv4/udp_offload.c:812) inet_gro_receive (net/ipv4/af_inet.c:1539) dev_gro_receive (net/core/gro.c:515) gro_receive_skb (net/core/gro.c:633) cpu_map_kthread_run (kernel/bpf/cpumap.c:395) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Kernel panic - not syncing: KASAN: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81003", "url": "https://ubuntu.com/security/CVE-2026-81003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: filter frames in afiucv_hs_rcv() by ingress device afiucv_hs_rcv() selects a socket from iucv_sk_list by matching four 8-byte name fields in the transport header alone. No check is made against the net_device the frame arrived on. This can cause a frame arriving on any netdev to be delivered to an AF_IUCV socket. Three problems follow. First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hs_dev == NULL. iucv_sock_bind() takes the classic path whenever the requested userid matches iucv_userid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucv_hs_callback_syn() for such a match inherits hs_dev = NULL and transport = AF_IUCV_TRANS_HIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable. Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections Third, all AF_IUCV sockets live in init_net, as iucv_sock_alloc() calls sk_alloc(&init_net, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAP_NET_RAW capability valid within that namespace can send a raw ETH_P_AF_IUCV frame on its own lo device and have it matched against init_net sockets. Fix all three by skipping any socket whose hs_dev does not match the ingress device. A classic z/VM IUCV socket has hs_dev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hs_dev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hs_dev is always a device in init_net (iucv_sock_bind() scans for_each_netdev_rcu(&init_net, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket. Note that AF_IUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81005", "url": "https://ubuntu.com/security/CVE-2026-81005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: si: Fix NULL pointer dereference after failed registration try_smi_init() allocates new_smi->si_sm and later calls ipmi_register_smi_mod(), which maps to ipmi_add_smi(). During ipmi_add_smi(), the upper IPMI message handler obtains the initial BMC device information through __bmc_get_device_id(). This can fail if the BMC does not return a successful response to the Get Device ID command. When the BMC returns a nonzero completion code, the device-id helper retries the command and eventually returns -EIO if the device ID still cannot be fetched. On this failure path, ipmi_add_smi() logs \"Unable to get the device id\" and goes to out_err_started, where it invokes the lower driver's shutdown callback. try_smi_init() then logs the returned registration failure: ipmi_si IPI0001:00: IPMI message handler: Unable to get the device id: -5 ipmi_si IPI0001:00: Unable to register device: error -5 For ipmi_si, the shutdown callback is shutdown_smi(), which cleans up the SI state machine data, frees smi_info->si_sm, and sets smi_info->si_sm and smi_info->intf to NULL. However, intf->in_shutdown is not set on this failed-registration rollback path. Therefore, the asynchronous redo_bmc_reg work item can still retry BMC device-id probing after the lower driver has already cleared its SI state machine data. In the observed case, that retry path reached start_next_msg(), which passed the NULL smi_info->si_sm pointer to the selected KCS state machine handler: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Workqueue: events redo_bmc_reg [ipmi_msghandler] RIP: start_kcs_transaction+0x2c/0x190 [ipmi_si] Call Trace: start_next_msg+0x50/0x80 [ipmi_si] check_start_timer_thread.part.9+0x3b/0x50 [ipmi_si] sender+0x69/0x80 [ipmi_si] i_ipmi_request+0x2ac/0x9d0 [ipmi_msghandler] __get_device_id.isra.29+0xaa/0x180 [ipmi_msghandler] __bmc_get_device_id+0xef/0x950 [ipmi_msghandler] redo_bmc_reg+0x52/0x60 [ipmi_msghandler] process_one_work+0x1a7/0x360 Set intf->in_shutdown on the out_err_started path before invoking the lower driver's shutdown callback. This prevents later redo_bmc_reg retries from using an interface whose lower driver state has been cleaned up, and applies the same shutdown state to other IPMI interfaces as well.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81007", "url": "https://ubuntu.com/security/CVE-2026-81007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: validate write message length ipmb_write() read message fields before validating the length byte. A zero or short write can read uninitialized stack bytes. A length smaller than the SMBus header underflows the block write length. Require a non-empty buffer and the minimum IPMB request length. Also require the length byte plus payload before parsing the message.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81008", "url": "https://ubuntu.com/security/CVE-2026-81008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: Fix use after free in icc_get() and of_icc_get_by_index() In of_icc_get_by_index() and icc_get(), if the dynamic allocation for path->name fails via kasprintf(), the error handling path directly calls kfree(path) to free the path object and returns an error. However, prior to this point, path_find() calls path_init(), which already links the path's requests into the req_list of the respective interconnect nodes via hlist_add_head(). Directly invoking kfree(path) leaves dangling pointers in the hlist. A subsequent call to icc_get() or icc_set_bw() will traverse or modify these corrupted lists, triggering a slab use afterfree. KASAN report showing the vulnerability when reproducing via debugfs: BUG: KASAN: slab-use-after-free in path_find+0x6f8/0xcfc Write of size 8 at addr fff000000d43f748 by task sh/1 ... Call trace: kasan_report+0xac/0xfc path_find+0x6f8/0xcfc icc_get+0x148/0x380 icc_get_set+0xf8/0x2d0 ... Freed by task 1: kfree+0x1a0/0x4a4 icc_get+0x2cc/0x380 icc_get_set+0xf8/0x2d0 Fix this by replacing kfree(path) with the proper teardown function, icc_put(path), which safely removes the requests from the req_list using hlist_del() and drops the provider usage references before freeing the memory. Additionally, in icc_get(), ensure that the icc_lock mutex is released prior to calling icc_put(path) to avoid a deadlock, as icc_put() internally acquires the same lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81011", "url": "https://ubuntu.com/security/CVE-2026-81011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: pass validated element count to package parsers The per-type package parsers are handed the wrong element count. hp_init_bios_package_attribute() validates obj->package.count and then calls one of the five hp_populate_*_package_data() wrappers (string, integer, enumeration, ordered list, password). Each wrapper forwards a count to its hp_populate_*_elements_from_package() parser, but instead of forwarding the validated obj->package.count it derives the count from elements[0]. elements[0] is the NAME field and is always an ACPI_TYPE_STRING, so reading ->package.count from it in fact reads ->string.length through the union acpi_object. The parsers thus bound themselves against the length of the name string rather than against the real number of elements in the package. This is safe today because hp_init_bios_package_attribute() refuses any package that has fewer than the type's element count, so a parser only ever runs on a full package and never reads past it regardless of the bogus bound. An upcoming change relaxes that check to accept shorter packages. Once a parser can receive fewer elements than its per-type count, a bound taken from the name length no longer reflects the array size, and the \"elem < count\" loop conditions and \"elem + n >= count\" sub-loop guards read past the end of elements[] - an out-of-bounds heap read. Forward the validated obj->package.count to every *_package_data() wrapper so the parsers bound themselves against the real package size. This does not change behaviour for the packages that enumerate correctly today and is a prerequisite for accepting shorter packages safely.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81012", "url": "https://ubuntu.com/security/CVE-2026-81012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix off-by-one write in hp_get_string_from_buffer() hp_get_string_from_buffer() clamps the converted string length against the destination buffer size with \"size > dst_size\", so when the converted length is exactly equal to dst_size, conv_dst_size is left at dst_size and the unconditional NUL terminator write \tdst[conv_dst_size] = 0; lands one byte past the destination buffer. This is the same shape of bug as the previously fixed off-by-one in hp_convert_hexstr_to_str(): the buffer is sized correctly for the content, but the terminator write is never checked against that size. Fix by changing the comparison to \">=\" so conv_dst_size is always left with room for the terminator. All fixed-size destinations that reach this function (path[512], current_value[512], current_password/current_value[64], and the per-entry buffers in encodings[][512] and prerequisites[][512]) are affected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81013", "url": "https://ubuntu.com/security/CVE-2026-81013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix heap OOB read on empty password write validate_password_input() computes length = strlen(buf) and then checks buf[length - 1] to strip a trailing newline, without checking that length is nonzero first. Writing an empty string (a bare '\\n') to current_password or new_password gives length == 0, and buf[length - 1] reads buf[-1], one byte before the heap allocation holding the copied input. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] Read of size 1 at addr ffff88811bd8da9f by task sh/13740 ... store_password_instance.constprop.0+0x223/0x2a0 [hp_bioscfg] current_password_store+0x14/0x20 [hp_bioscfg] ... The buggy address is located 23 bytes to the right of allocated 8-byte region [ffff88811bd8da80, ffff88811bd8da88) Reproduced identically via new_password_store. Execution continues past the bad read (the garbage byte only affects whether \"length\" is decremented by one), so the write completes and returns success; this is a pure information read past the buffer, not a crash, but it is still an out-of-bounds access KASAN correctly flags. Fix by only checking buf[length - 1] when length is nonzero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81014", "url": "https://ubuntu.com/security/CVE-2026-81014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and kek_store() sk_store() and kek_store() strip a trailing newline from the sysfs write before allocating the key buffer: \tlength = count; \tif (buf[length - 1] == '\\n') \t\tlength--; \tbioscfg_drv.spm_data.signing_key = kmemdup(buf, length, GFP_KERNEL); but then pass the original \"count\" (not \"length\") as the copy size to hp_wmi_perform_query(), which memcpy()s that many bytes out of the \"length\"-sized allocation, reading one byte past it whenever the write ends in a newline, the normal case for a shell \"echo\" into sysfs. KASAN confirms this directly: BUG: KASAN: slab-out-of-bounds in hp_wmi_perform_query+0x1e9/0x460 [hp_bioscfg] Read of size 28 at addr ffff88813c8e2b80 by task python3/16022 ... sk_store+0xa7/0x240 [hp_bioscfg] kernfs_fop_write_iter+0x3e1/0x5d0 ... The buggy address is located 0 bytes inside of allocated 27-byte region [ffff88813c8e2b80, ffff88813c8e2b9b) Reproduced identically for kek_store, and at multiple write sizes (28, 57, 201 bytes), each time reading exactly one byte past a kmemdup() allocation one byte smaller than the write. Fix by passing \"length\" instead of \"count\" to hp_wmi_perform_query() in both functions.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-81017", "url": "https://ubuntu.com/security/CVE-2026-81017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/chrome: sensorhub: Bound the EC-reported sensor number Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89438", "url": "https://ubuntu.com/security/CVE-2026-89438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate logical CPU id and clos id Validate max CLOS ID and logical CPU ID for core power feature. Reject any clos level or logical CPU number greater than the supported maximum. These are used to calculate MMIO offset.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89440", "url": "https://ubuntu.com/security/CVE-2026-89440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: via-sdmmc: stop card-detect handling on probe failure request_irq() registers the SD card-detect interrupt and the probe enables it before mmc_add_host() runs. If mmc_add_host() fails, the error path only unmaps the registers and returns: the interrupt stays registered, so the handler keeps running against the host once it is freed. via_sdc_isr() dereferences sdhost and its MMIO base and schedules carddet_work, which via_sdc_card_detect() also runs against freed memory through its container_of() dereference. Add a probe-error path that disables and frees the interrupt and cancels carddet_work before unmapping. carddet_work can re-enable the device interrupt via via_reset_pcictrl(), which restores PCIINTCTRL, so mask it again after cancelling the work. This issue was found by an in-house static analysis tool and confirmed by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89442", "url": "https://ubuntu.com/security/CVE-2026-89442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate socket ID in clos_assoc ioctl isst_if_clos_assoc() validates the user-supplied socket_id with 'socket_id > topology_max_packages()', but isst_common.sst_inst[] is allocated with topology_max_packages() entries, so the valid index range is [0, topology_max_packages()). The '>' comparison lets socket_id == topology_max_packages() pass and index one entry past the array. In addition, isst_common.sst_inst[socket_id] is NULL for an in-range package that has no bound TPMI SST instance, and the pointer is used without a NULL check. Both the out-of-bounds entry and the NULL pointer are then dereferenced by map_partition_power_domain_id() and the following power_domain_info access. Reject socket_id >= topology_max_packages() and a NULL sst_inst, matching the checks already performed by get_instance().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89443", "url": "https://ubuntu.com/security/CVE-2026-89443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Validate level in perf mask ioctls isst_if_get_perf_level_mask() and isst_if_get_base_freq_mask() use the user-provided level as an index into perf_levels[] via _read_pp_level_info() and _read_bf_level_info(), but neither helper validates it first. The adjacent level-info helpers reject levels above max_level before reading the same per-level register block. Add the same bounds checks to the mask helpers, and reject disabled SST-PP levels in isst_if_get_perf_level_mask() to match isst_if_get_perf_level_info(). This prevents out-of-bounds reads from the per-level offset table on invalid ioctl input.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89444", "url": "https://ubuntu.com/security/CVE-2026-89444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc (\"platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data\"). Remove the remaining dump from the BIOS attribute path.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89448", "url": "https://ubuntu.com/security/CVE-2026-89448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Force requesting ACS when tboot is enabled Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu().", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89451", "url": "https://ubuntu.com/security/CVE-2026-89451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/sva: Set handle->dev before the SVA handle is visible iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommu_sva_unbind_device() can then dereference it via handle->dev->iommu_group. Initialize handle->dev before releasing iommu_sva_lock so any visible SVA handle is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89456", "url": "https://ubuntu.com/security/CVE-2026-89456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Propagate partial completion length across ERP recovery dasd_default_erp_postaction() copies the timing and device state from the finished ERP request back to the original request but drops proc_bytes. A request that was partially completed, an ESE read of a not-yet-allocated track returns fewer bytes than requested, and then recovered through the ERP chain loses its partial-completion length. __dasd_cleanup_cqr() then sees proc_bytes == 0 and completes the whole request instead of requeueing the remainder, silently returning zeroed data for the part that was never read. Carry proc_bytes over to the original request like the other per-request state.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89457", "url": "https://ubuntu.com/security/CVE-2026-89457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Guard sysfs discipline callbacks against unallocated private data Several sysfs show/store handlers call a discipline callback that dereferences device->private, either directly or through the DASD_DEFINE_ATTR() macro. During dasd_generic_set_online() the discipline is assigned before check_device() allocates device->private, so an unprivileged read of one of these world-readable attributes in that window dereferences a NULL pointer and panics. Guard the dereference inside each callback that actually touches device->private.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89458", "url": "https://ubuntu.com/security/CVE-2026-89458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Do not complete a failed ESE read as successful dasd_int_handler() completes an NRF read of an unallocated ESE track by calling ese_read() and unconditionally marking the request DASD_CQR_SUCCESS. dasd_eckd_ese_read() can return an error before it has zeroed the destination buffer: a failed sense-data parse or a current track outside the requested range both return early, leaving the destination pages untouched. The request is still completed successfully, so the block layer is handed stale / uninitialized memory instead of zeros. Check the ese_read() return value and fail the request through the normal error path instead of forcing DASD_CQR_SUCCESS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89461", "url": "https://ubuntu.com/security/CVE-2026-89461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: synchronize work cancellation on suspend max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89462", "url": "https://ubuntu.com/security/CVE-2026-89462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: propagate register read errors max17040_get_vcell() and max17040_get_soc() ignore errors returned by regmap_read(). When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as a valid voltage or state of charge. The polling worker can also replace the cached state of charge with the bogus value and emit a spurious change event. Propagate read errors through the power supply get_property callback and keep the last valid cached state of charge when polling fails.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89463", "url": "https://ubuntu.com/security/CVE-2026-89463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: ucs1002: fix use-after-free on remove ucs1002 has no remove callback, so unbind runs entirely through devm. The alert IRQ handler queues the health_poll delayed work, and the work reschedules itself while the chip reports a bad-health condition. devm frees the alert IRQ, which only synchronizes the handler; it does not cancel the delayed work, which can then run after devm frees the driver data and dereference it. Register health_poll with devm_delayed_work_autocancel() before the alert IRQ is requested. devm then frees the IRQ before cancelling the work, so the handler can no longer queue it and the work is cancelled before the driver data is freed. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89464", "url": "https://ubuntu.com/security/CVE-2026-89464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: twl4030_charger: cancel workers via devm bci is devm-allocated. Two workers (bci->work and bci->current_worker) dereference it. twl4030_bci_remove() disables charging and masks interrupts. It cancels neither worker. A worker pending at remove() can run after devm frees bci. The USB transceiver comes from devm_usb_get_phy_by_node(). devm unregisters its notifier only after remove() returns. A cancel_work_sync() in remove() can then race a notifier reschedule. devm_work_autocancel() and devm_delayed_work_autocancel() avoid that. They cancel the workers during devm release, before bci is freed. The current_worker is registered first, since devm will cancel in reverse order and bci->work can reschedule current_worker. [Move comment about order into the commit message]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89465", "url": "https://ubuntu.com/security/CVE-2026-89465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: quiesce delayed work before teardown The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work. pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself. rt9455_remove() cancels max_charging_time_work before batt_presence_work. The latter can therefore queue max_charging_time_work after it has already been cancelled: rt9455_remove() workqueue cancel pwr_rdy_work cancel max_charging_time_work batt_presence_work queues max_charging_time_work cancel batt_presence_work return devres frees rt9455_info max_charging_time_work dereferences rt9455_info The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls. If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued. A pending callback can then access rt9455_info after it has been freed. Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path. Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89466", "url": "https://ubuntu.com/security/CVE-2026-89466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: qcom_battmgr: terminate the strings from firmware The qcom_battmgr_sc8280xp_strcpy() takes a Pascal-style string when the firmware sends one. Otherwise it copies all BATTMGR_STRING_LEN bytes and leaves the destination without a terminator. Those destinations are model_number, serial_number and oem_info, each BATTMGR_STRING_LEN and declared next to each other. They go out to user space as val->strval, which power_supply_format_property() prints with \"%s\", so a firmware string that fills the whole field makes that read run into the following members. Use strscpy() so the copy always terminates, the way the SM8350 path already does for the same field.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89468", "url": "https://ubuntu.com/security/CVE-2026-89468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8788-charger: fix use-after-free on remove lp8788_charger_remove() flushes charger_work before unregistering the IRQs. An IRQ thread can queue charger_work after flush_work() has returned. The work can then run after devres frees pchg and dereference it in lp8788_charger_event(). Unregister the IRQs first. free_irq() waits for any running threaded handler, so no handler can queue more work afterwards. Then use cancel_work_sync() to cancel pending work or wait for running work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89469", "url": "https://ubuntu.com/security/CVE-2026-89469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: lp8727: fix use-after-free in lp8727_release_irq() lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89470", "url": "https://ubuntu.com/security/CVE-2026-89470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS Currently the cros_usbpd-charger driver probe iterates based on raw charger port count returned by the embedded controller. The only check is against the number of USB PD ports which the embedded controller also defines. A malicious embedded controller could return an inaccurate port count (up to 255) resulting in an out of bounds write and subsequent memory corruption. Update helper functions in cros_usbpd-charger to limit port counts to EC_USB_PD_MAX_PORTS.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89471", "url": "https://ubuntu.com/security/CVE-2026-89471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: cros_usbpd-charger: bound the EC-reported port count cros_usbpd_charger_probe() reads two port counts from the EC and uses one of them, num_charger_ports, as the loop bound when populating a fixed-size array: \tstruct port_data *ports[EC_USB_PD_MAX_PORTS];\t/* 8 entries */ \t... \tfor (i = 0; i < charger->num_charger_ports; i++) \t\tcharger->ports[charger->num_registered_psy++] = port; Both num_usbpd_ports (from EC_CMD_USB_PD_PORTS) and num_charger_ports (from EC_CMD_CHARGE_PORT_COUNT) are u8 values reported by the EC. The only validation is a sanity check that compares the two EC-reported values against each other: \tif (num_charger_ports < num_usbpd_ports || \t num_charger_ports > num_usbpd_ports + 1) \t\treturn -EPROTO; It never checks either count against EC_USB_PD_MAX_PORTS, the size of the ports[] array. A malfunctioning, malicious or compromised EC that reports num_usbpd_ports == num_charger_ports == N for any N > 8 (for example both 255) passes this check, and the loop then writes N pointers into the 8-entry ports[] array embedded in the devm_kzalloc()'d charger_data, overflowing it by up to 255 - 8 = 247 entries (~1976 bytes): a slab out-of-bounds write. Reject a port count larger than the ports[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89472", "url": "https://ubuntu.com/security/CVE-2026-89472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: register regulators before exposing sysfs charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available. Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path. Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure). This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design. Found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89473", "url": "https://ubuntu.com/security/CVE-2026-89473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq25890: Fix power_supply reference leak bq25890_fw_probe() acquires a reference to a secondary charger using power_supply_get_by_name(), but the reference is not released on later probe failures or on driver detach. In particular, failures after bq25890_fw_probe() returns successfully, such as a failure in bq25890_hw_init(), also leak the reference. Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89474", "url": "https://ubuntu.com/security/CVE-2026-89474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq256xx: drain usb_work before freeing the charger The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89475", "url": "https://ubuntu.com/security/CVE-2026-89475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: bq24257: fix use-after-free on remove The STAT-pin interrupt is devm-managed, so it stays armed until the devm cleanup that runs after remove() returns. remove() cancels bq->iilimit_setup_work while the threaded handler can still fire; that handler reschedules the work and dereferences bq, so the work runs against freed memory once devm frees bq. Make the delayed work device-managed with devm_delayed_work_autocancel(), registered before the interrupt request. The devm cleanup then releases the interrupt first, so the handler can no longer reschedule the work, and cancels the work before bq is freed. The explicit cancel_delayed_work_sync() in remove() is no longer needed and is dropped. Found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89476", "url": "https://ubuntu.com/security/CVE-2026-89476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix stream->outcnt underflow on duplicate RECONF responses A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it. Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89477", "url": "https://ubuntu.com/security/CVE-2026-89477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix NULL deref on untransmitted RECONF completion sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out() and sctp_process_strreset_resp() complete a pending stream reconfiguration request by stopping the reconf timer on the transport it was sent on: \tt = asoc->strreset_chunk->transport; \tif (timer_delete(&t->reconf_timer)) \t\tsctp_transport_put(t); chunk->transport is assigned by __sctp_packet_append_chunk() when the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same point. A request already published in asoc->strreset_chunk but not yet transmitted has neither, so completing it dereferences NULL. Two ways to get there. sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok without sending anything when the address being removed is the association's last one, and sctp_outq_flush_ctrl() then leaves every non-ASCONF control chunk queued; as only sctp_process_asconf_ack() clears that flag, it persists. An unprivileged process that removes such an address and then asks for a stream reset panics the kernel from softirq. A peer needs neither ASCONF nor local help: sctp_cmd_interpreter() uncorks the outqueue only once the whole packet has been processed, so a reply built while walking a RECONF chunk stays untransmitted for the rest of that walk, and one RECONF chunk carrying [Incoming SSN Reset Request, Outgoing SSN Reset Request, Response] -- or two RECONF chunks in one packet -- reaches the same dereference. KASAN: null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] RIP: 0010:timer_delete+0x67/0x110 Call Trace: sctp_process_strreset_addstrm_out (net/sctp/stream.c:832) sctp_sf_do_reconf (net/sctp/sm_statefuns.c:4212) sctp_do_sm (net/sctp/sm_sideeffect.c:1172) sctp_assoc_bh_rcv (net/sctp/associola.c:1044) sctp_rcv (net/sctp/input.c:243) ip_local_deliver (net/ipv4/ip_input.c:262) process_backlog (net/core/dev.c:6680) A response can only acknowledge a request that was actually sent, so do not match asoc->strreset_chunk while chunk->transport is NULL. Guarding the lookup covers all three completion sites.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89478", "url": "https://ubuntu.com/security/CVE-2026-89478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: drop a chunk if its transport was removed sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed. An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock(). The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state. Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89479", "url": "https://ubuntu.com/security/CVE-2026-89479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stop processing a packet once its association is deleted sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference. A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed. The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context. The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path. sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89480", "url": "https://ubuntu.com/security/CVE-2026-89480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89481", "url": "https://ubuntu.com/security/CVE-2026-89481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix host memory disclosure on R2T for a read command nvme_tcp_handle_r2t() does not check the direction of the request the R2T refers to. A malicious controller can send an R2T for a READ and the host will answer it: nvme_tcp_setup_h2c_data_pdu() builds the H2CData header and nvme_tcp_try_send_data() sends the request's data buffer. That buffer is the READ destination, so its contents go to the controller. The command then completes normally and nothing is logged. Against a test controller that answers every READ with an R2T, a 4096 byte buffered read returned all 4096 bytes, split over two R2Ts. The pages contained stale kernel data, including an array of struct page pointers. Reject an R2T for a request that is not a write.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89482", "url": "https://ubuntu.com/security/CVE-2026-89482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone Commit 25e5cb780e62 (\"nvme-tcp: fix possible crash in write_zeroes processing\") established that blk_rq_payload_bytes() must not be read without first checking blk_rq_nr_phys_segments(), and recorded the result in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side was left as it was. The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments but a non-zero blk_rq_bytes(), so setup leaves req->iter untouched while the receive gate lets a C2HData through and nvme_tcp_recv_data() copies into whatever the previous command on that tag left there. The driver-private area is zeroed only when the tag set is allocated. Reproduced with a test target that leaves a residual iterator on a tag and then sends a C2HData for a WRITE_ZEROES command on the same tag: BUG: KASAN: wild-memory-access in _copy_to_iter+0x642/0x1330 Write of size 512 at addr ffe728c2175dfa81 by task kworker/0:1H/103 CPU: 0 UID: 0 PID: 103 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy) 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 Workqueue: nvme_tcp_wq nvme_tcp_io_work Call Trace: dump_stack_lvl+0x53/0x70 kasan_report+0xce/0x100 ? _copy_to_iter+0x642/0x1330 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x642/0x1330 ? __pfx_sock_has_perm+0x10/0x10 ? worker_thread+0x45b/0xd10 ? __pfx__copy_to_iter+0x10/0x10 ? _raw_spin_lock_bh+0x83/0xe0 ? __pfx__raw_spin_lock_bh+0x10/0x10 __skb_datagram_iter+0xf3/0x820 ? __pfx_simple_copy_to_iter+0x10/0x10 ? __asan_memcpy+0x3c/0x60 ? skb_copy_bits+0x58d/0x830 skb_copy_datagram_iter+0x37/0x120 nvme_tcp_recv_skb+0xa07/0x4320 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 __tcp_read_sock+0x1ab/0x810 ? __pfx_nvme_tcp_recv_skb+0x10/0x10 ? __pfx_lock_sock_nested+0x10/0x10 ? __pfx___tcp_read_sock+0x10/0x10 nvme_tcp_try_recv+0x152/0x1e0 ? __pfx_nvme_tcp_try_recv+0x10/0x10 ? __pfx_mutex_unlock+0x10/0x10 nvme_tcp_io_work+0x1e4/0x6c0 ? __schedule+0x181a/0x49f0 ? __pfx_nvme_tcp_io_work+0x10/0x10 process_one_work+0x633/0x1030 Keep the blk_rq_payload_bytes() test and add req->data_len to it. The old test is what rejects a C2HData naming a tag that is no longer in flight, because blk_update_request() zeroes rq->__data_len on completion; req->data_len and req->curr_bio are driver-private and survive completion, so they cannot stand in for it. Setup initialises the iterator only when both req->curr_bio and req->data_len are set, so the gate now tests the same two.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89483", "url": "https://ubuntu.com/security/CVE-2026-89483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: zero the discard fallback page nvme_setup_discard() always maps sizeof(struct nvme_dsm_range) * NVME_DSM_MAX_RANGES = 4096 bytes as the DSM payload however many ranges the command declares, because some devices ignore the 'Number of Ranges' field - the Fixes: commit records two that read past the declared ranges. A single-range discard fills only the first 16 bytes. Normally the buffer comes from kzalloc() and the other 4080 bytes are zero. When that allocation fails the code falls back to the per-controller ctrl->discard_page, which nvme_init_ctrl() obtains with alloc_page(GFP_KERNEL) and nothing ever zeroes, so those 4080 bytes are whatever the page last held and are handed to the controller. Reaching it requires the kzalloc(GFP_ATOMIC | __GFP_NOWARN) to fail, that is memory pressure; it is not remotely triggerable. Failing the allocation under KMSAN reproduces it, with the leaked tail full of vmemmap struct page pointers. The extent in the report is a partial transfer of the payload, not the whole 4096 bytes; the 16-byte boundary in it is the one declared range: [ 11.991601] BUG: KMSAN: uninit-value in dma_map_phys+0x14c8/0x1900 [ 11.991969] dma_map_phys+0x14c8/0x1900 [ 11.992220] dma_map_page_attrs+0xcf/0x130 [ 11.992485] e1000_xmit_frame+0x4099/0x6d10 [ 11.992768] dev_hard_start_xmit+0x22f/0xa80 [ 11.993068] sch_direct_xmit+0x35c/0xcb0 [ 11.993315] __dev_queue_xmit+0x1ee5/0x5eb0 [ 11.993608] ip_finish_output2+0x1903/0x1c30 [ 11.993881] ip_finish_output+0x288/0x870 [ 11.994125] ip_output+0x15e/0x400 [ 11.994365] __ip_queue_xmit+0x1e85/0x1fb0 [ 11.994639] ip_queue_xmit+0x60/0x80 [ 11.994899] __tcp_transmit_skb+0x4e71/0x5fa0 [ 11.995210] tcp_write_xmit+0x3a36/0x9160 [ 11.995533] __tcp_push_pending_frames+0xc5/0x3c0 [ 11.995854] tcp_push+0x7dc/0x840 [ 11.996076] tcp_sendmsg_locked+0x766c/0x8400 [ 11.996371] tcp_sendmsg+0x4b/0x90 [ 11.996572] inet_sendmsg+0x134/0x2a0 [ 11.996823] __sock_sendmsg+0x265/0x360 [ 11.997076] sock_sendmsg+0x100/0x1e0 [ 11.997293] nvme_tcp_try_send+0x196f/0x6370 [ 11.997605] nvme_tcp_queue_rq+0x1d54/0x20b0 [ 11.997882] blk_mq_dispatch_rq_list+0x5ee/0x2e50 [ 11.998175] __blk_mq_sched_dispatch_requests+0x16dc/0x24a0 [ 11.998539] blk_mq_sched_dispatch_requests+0x11b/0x2c0 [ 11.998865] blk_mq_run_work_fn+0x13b/0x280 [ 11.999146] process_scheduled_works+0x966/0x1ad0 [ 11.999465] worker_thread+0xe44/0x1480 [ 11.999709] kthread+0x53b/0x600 [ 11.999927] ret_from_fork+0x29f/0x7c0 [ 12.000191] ret_from_fork_asm+0x1a/0x30 [ 12.000460] [ 12.000558] Uninit was created at: [ 12.000788] __alloc_frozen_pages_noprof+0x8bf/0xd30 [ 12.001096] alloc_pages_mpol+0x1d0/0x5f0 [ 12.001326] alloc_pages_noprof+0x102/0x290 [ 12.001627] nvme_init_ctrl+0x5a3/0x9f0 [ 12.001891] nvme_tcp_create_ctrl+0xd75/0x19b0 [ 12.002170] nvmf_dev_write+0x4c68/0x4fd0 [ 12.002426] vfs_write+0x587/0x1a10 [ 12.002636] __x64_sys_write+0x207/0x4f0 [ 12.002874] x64_sys_call+0x2ff0/0x3ea0 [ 12.003123] do_syscall_64+0x147/0x3b0 [ 12.003400] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 12.003680] [ 12.003777] Bytes 16-2843 of 2844 are uninitialized [ 12.004068] Memory access of size 2844 starts at ffff888109f82000 [ 12.004412] [ 12.004530] CPU: 0 UID: 0 PID: 101 Comm: kworker/0:1H Not tainted 7.2.0-rc5-NVMECTL-gf5098b6bae76 #1 PREEMPT(lazy) [ 12.005127] 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 [ 12.005762] Workqueue: kblockd blk_mq_run_work_fn [ 12.006073] ===================================================== Allocate the page with __GFP_ZERO. The single allocation site covers every use of it: bytes no discard has written stay zero, and bytes one did write hold that controller's own range list, which it has already been sent.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89484", "url": "https://ubuntu.com/security/CVE-2026-89484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: fix NULL dereference on lockowner allocation failure nlmclnt_locks_init_private() installs NLM file lock operations even when nlmclnt_find_lockowner() fails to allocate a lockowner. nlmclnt_proc() then returns -ENOMEM, but the VFS still tears down the partially initialized file_lock and calls locks_release_private(). That invokes nlmclnt_locks_release_private(), which dereferences fl->fl_u.nfs_fl.owner and crashes because the owner was never installed. Clear fl_ops before attempting to initialize the NLM private state, and install the NLM lock operations only after a lockowner has been allocated successfully.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89485", "url": "https://ubuntu.com/security/CVE-2026-89485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89487", "url": "https://ubuntu.com/security/CVE-2026-89487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: only skb_tx_error() a packet we are about to drop queue_userspace_packet() borrows the packet skb -- it only copies it into a private netlink message (user_skb) and does not own it; on return do_execute_actions() keeps forwarding it through the flow's remaining actions. Its error path nevertheless calls skb_tx_error(skb), which via skb_zcopy_clear() does skb_shinfo(skb)->flags &= ~SKBFL_ALL_ZEROCOPY, stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s kerneldoc says \"skb must be freed afterwards\"). For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG is what makes esp_input() skb_cow_data() before in-place AEAD; once it is stripped a later local ESP-in-UDP delivery decrypts in place over pages the sender does not own -- an unprivileged page-cache write (the \"Fragnesia\" primitive). do_execute_actions() ignores output_userspace()'s return value, so any action after a failed USERSPACE upcall inherits the stripped skb. Move the skb_tx_error() to the flow-miss drop path - the \"default\" branch of ovs_dp_process_packet()'s switch(error), before kfree_skb(). The call has been here since commit 36d5fe6a0007 (\"core, nfqueue, openvswitch: Orphan frags in skb_zerocopy and handle errors\") but was harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate in-place decrypt; only then did stripping it on a still-forwarded skb become a page-cache write primitive.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89489", "url": "https://ubuntu.com/security/CVE-2026-89489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: fix arbitrary kernel memory access via or1k_atomic syscall sys_or1k_atomic() (syscall 244 in the \"or1k\" ABI) takes two user pointers, v1 and v2, and swaps the words they point to in hand-written assembly. l.lwz r29,0(r4) l.lwz r27,0(r5) l.sw 0(r4),r27 l.sw 0(r5),r29 The pointers are not checked with access_ok(). The four memory accesses also have no exception table entries. A caller passes a kernel address as either pointer, and the syscall reads from and writes to it directly. This gives an unprivileged process a kernel read/write primitive. It overwrites kernel data such as the sys_call_table, gaining code execution in kernel context. Check both pointers before entering the critical section. Add fixups for the four memory accesses so faults on valid but unmapped user addresses return -EFAULT. [shorne@gmail.com: fix comment style]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89490", "url": "https://ubuntu.com/security/CVE-2026-89490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with \tctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask \t~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 (\"exfat: Fix bitwise operation having different size\") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: \tctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89491", "url": "https://ubuntu.com/security/CVE-2026-89491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin() Patch series \"ocfs2: cluster: o2hb_region_pin() fixes\", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: 58a3158a5d17 (\"ocfs2/cluster: Pin/unpin o2hb regions\"): 1) It is called with o2hb_live_lock (a spinlock) held, but the underlying configfs_depend_item() sleeps (takes inode rwsem and pins the filesystem). This triggers BUG under CONFIG_DEBUG_ATOMIC_SLEEP. 2) When called from the configfs drop_item callback, it creates a lock order inversion: parent inode_lock -> configfs root inode_lock, which can deadlock against subsystem unregistration paths taking root -> parent. 3) If pinning fails partway through o2hb_region_inc_user(), the o2hb_dependent_users counter is leaked and partially-pinned regions are never released, leaving heartbeat regions unprotected on subsequent mounts. Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each sleeping configfs_depend_item() call, using a config_item reference to keep the region alive while unlocked. Patch 2 adds a from_callback parameter to select configfs_depend_item_unlocked() when called from configfs context, avoiding the inode_lock nesting. Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and decrement the counter on failure. This patch (of 3): o2hb_region_pin() is always called with the o2hb_live_lock spinlock held (from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins the configfs filesystem and takes the configfs root inode rwsem. Under CONFIG_DEBUG_ATOMIC_SLEEP this triggers: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c in_atomic(): 1, ... name: mount.ocfs2 down_write configfs_depend_item o2hb_region_pin o2hb_region_inc_user o2hb_register_callback dlm_register_domain_handlers ... ocfs2_dlm_init ocfs2_mount_volume ocfs2_fill_super Rework o2hb_region_pin() to pin one region at a time with the lock dropped across the sleeping call: under o2hb_live_lock find the next eligible region and take a config_item reference to keep it alive, drop the lock, call o2nm_depend_item(), then retake the lock and record the pin. The config_item_put() is done with the lock released as well, since o2hb_region_release() also acquires o2hb_live_lock and can sleep. The region list may change while unlocked, so the scan restarts from the top after each pin. Local heartbeat still pins only the matching region; global heartbeat pins all eligible regions. The unpin path is unaffected: configfs_undepend_item() only takes a spinlock and does not sleep.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89567", "url": "https://ubuntu.com/security/CVE-2026-89567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: bound shrinker scans by examined checkpoint buffers The jbd2 shrinker currently accounts only checkpoint buffers that it successfully releases against nr_to_scan. Busy buffers therefore do not consume the scan budget. If a checkpoint transaction contains mostly busy buffers, the shrinker can scan its entire checkpoint list while holding journal->j_list_lock. Large checkpoint lists can result in excessive lock hold times and leave other CPUs spinning on j_list_lock, causing soft lockups or RCU stalls. Pass nr_to_scan into journal_shrink_one_cp_list() and decrement it for every buffer examined, including busy buffers. Pass NULL from checkpoint cleanup paths so their existing full-list behavior is preserved. This restores the scan-budget semantics that existed before journal_shrink_one_cp_list() was changed to always scan a complete checkpoint list.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89532", "url": "https://ubuntu.com/security/CVE-2026-89532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix pcl_for_each_segment for empty chunks When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults. A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault. xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write() chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */ list_add_tail(&chunk->ch_list, &pcl->cl_chunks) /* fill loop iterates zero times for wire segcount 0 */ svc_rdma_get_inv_rkey() pcl_for_each_chunk(rc_write_pcl) pcl_for_each_segment(segment, chunk) pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB read -> GPF */ Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89533", "url": "https://ubuntu.com/security/CVE-2026-89533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: svcrdma: Fix offset arithmetic in read_chunk_range svc_rdma_read_chunk_range() walks a Read chunk's segment list to build a sub-range starting at byte offset and spanning length bytes for a Position-Zero or Call chunk. Two arithmetic defects in the per-segment loop produce wrong DMA lengths and a u32 underflow: pcl_for_each_segment(segment, chunk) { if (offset > segment->rs_length) { offset -= segment->rs_length; continue; } dummy.rs_handle = segment->rs_handle; dummy.rs_length = min_t(u32, length, segment->rs_length) - offset; dummy.rs_offset = segment->rs_offset + offset; First, the skip predicate uses '>' instead of '>='. When offset equals the segment's full rs_length, the segment is fully consumed and should be skipped, but the loop falls through into the body. The resulting dummy.rs_length is min_t(u32, length, rs_length) - rs_length, which underflows to a near-UINT_MAX u32 when length is smaller than rs_length, or is zero otherwise. Second, the length formula subtracts offset from the min_t() result rather than from segment->rs_length before the cap. For offset > 0 the segment's residual is rs_length - offset, not rs_length, so the cap must be applied to the residual. With the current bracketing, whenever length is smaller than rs_length - offset the per-segment length becomes length - offset instead of length, silently dropping offset bytes from the rebuilt chunk. Combined with the boundary case above it also enables the u32 underflow path, which propagates a huge nr_bvec into svc_rdma_build_read_segment() and a multi-MiB kmalloc_array_node() in svc_rdma_get_rw_ctxt(). Additionally, svc_rdma_read_call_chunk() can invoke this function with length == 0 when the last Read chunk ends exactly at the end of the Call chunk. With the corrected >= predicate, every segment is skipped and the function returns the initial -EINVAL, rejecting a valid request. Return success immediately when length is zero. Also break out of the loop once length is fully consumed to avoid passing zero-length segments to svc_rdma_build_read_segment(). Fix by using '>=' so a fully-consumed segment is skipped, by moving '- offset' inside min_t() so the cap is applied to the segment's residual length, by returning success for zero-length requests, and by stopping iteration when the requested range has been consumed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89536", "url": "https://ubuntu.com/security/CVE-2026-89536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: wait for in-flight client TLS handshake callback xs_tls_handshake_sync() gives xs_tls_handshake_done() a reference to the lower transport before submitting the handshake request. On timeout or signal, the synchronous waiter drops that reference after calling tls_handshake_cancel(). handshake_req_cancel() returns false when handshake_complete() has already marked the request complete. In that case the completion callback can still be running, so dropping the callback-owned reference in the waiter can free the lower transport before xs_tls_handshake_done() stores xprt_err or drops its own reference. If cancellation loses to completion, wait until xs_tls_handshake_done() signals handshake_done and let the callback release its reference. This mirrors the server-side handshake lifetime handling and keeps the timeout or signal return value unchanged.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89538", "url": "https://ubuntu.com/security/CVE-2026-89538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field gss_krb5_unwrap_v2() sets buf->len to a logical length, which can be much smaller than head[0].iov_len (the allocated receive-page capacity). It then calls xdr_buf_trim() with a trim length derived from the 16-bit \"extra count\" (ec) field in the Kerberos v2 token header. The ec field is authenticated by the post-decrypt memcmp() against the encrypted header copy, so a randomly-mutated value is rejected. However, any peer holding a valid GSS context can legitimately encrypt a token whose ec exceeds the plaintext length. Per RFC 4121, such a token is structurally malformed. Although xdr_buf_trim() now clamps the buf->len subtraction to avoid unsigned underflow, the buffer is still left in a semantically invalid state (zero length, inconsistent iov lengths) when ec is oversized. Reject these tokens before calling xdr_buf_trim(), giving callers a well-defined GSS_S_DEFECTIVE_TOKEN error and keeping the xdr_buf internally consistent. The wrapped blob begins at a nonzero offset -- both callers pass len as offset + opaque_len -- so buf->len still counts the offset bytes that precede the blob. Compare the trim length against the remaining wrapped segment, buf->len - offset, rather than the whole buffer; comparing against buf->len alone leaves an offset-wide window in which an oversized ec passes the test and xdr_buf_trim() cuts into the bytes ahead of the blob.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89539", "url": "https://ubuntu.com/security/CVE-2026-89539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: reject duplicate CREDS_VALUE options gssx_dec_option_array() walks the wire-supplied option array and, for every entry whose name matches CREDS_VALUE, calls gssx_dec_linux_creds() on the same struct svc_cred. That helper unconditionally installs a fresh groups_alloc() result into creds->cr_group_info without releasing whatever pointer was already there: for (i = 0; i < count; i++) { ... decode name ... if (length == sizeof(CREDS_VALUE) && memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) { err = gssx_dec_linux_creds(xdr, creds); ... } } A reply that carries two CREDS_VALUE entries therefore overwrites cr_group_info on the second iteration and orphans the group_info allocated by the first call. The earlier free_creds path only releases the last cr_group_info via free_svc_cred(), so the first allocation's refcount stays at one and its kvmalloc-backed storage is leaked. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply. Fix by tracking whether a CREDS_VALUE option has already been decoded and returning -EINVAL on any subsequent match, so the free_creds path releases the single group_info that was installed.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89540", "url": "https://ubuntu.com/security/CVE-2026-89540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sunrpc: init gssp_lock before publishing proc entry create_use_gss_proxy_proc_entry() publishes /proc/net/rpc/use-gss-proxy via proc_create_data() before init_gssp_clnt() runs mutex_init() on sn->gssp_lock. Once the dentry is linked under proc_subdir_lock it is immediately reachable from userspace, so a write that lands in the window drives set_gssp_clnt() into mutex_lock() on a zero-initialized struct mutex. create_use_gss_proxy_proc_entry(net) proc_create_data(\"use-gss-proxy\", ...) /* dentry live */ init_gssp_clnt(sn) mutex_init(&sn->gssp_lock) /* too late */ write_gssp() set_gssp_clnt(net) mutex_lock(&sn->gssp_lock) /* uninitialized */ gssp_rpc_create(...) sn->gssp_clnt = clnt mutex_unlock(&sn->gssp_lock) The window spans only the two statements between proc_create_data() returning and init_gssp_clnt(), so a writer reaches it only if the registering thread is preempted there while another task is already opening the freshly published file. register_pernet_subsys() runs in preemptible context under pernet_ops_rwsem, so that preemption is possible, and the window widens on auth_rpcgss module load, when the proc entry is created for every live net namespace whose tasks are already running. A writer that wins the race locks a zero-filled struct mutex. On CONFIG_DEBUG_MUTEXES the missing magic value trips a \"lock used without init\" splat; on a production kernel the fast path acquires the lock via CMPXCHG(owner, 0, current). In the latter case a second writer that arrives before init_gssp_clnt() re-zeroes owner can enter set_gssp_clnt() concurrently, shut down the first writer's clnt while it is still in use, and leak the loser's clnt. Fix by initializing sn->gssp_lock in sunrpc_init_net() so its lifetime matches the sunrpc_net it lives in. sn->gssp_clnt is already NULL from the kzalloc that backs net_generic storage, so the lazy helper is no longer needed; drop init_gssp_clnt(), its prototype, and the call from create_use_gss_proxy_proc_entry(). sunrpc.ko is a build-time dependency of auth_rpcgss.ko, so sunrpc_init_net() has always run on every netns before any auth_gss pernet init can publish the proc entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89541", "url": "https://ubuntu.com/security/CVE-2026-89541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 (\"SUNRPC: svcauth_gss: enforce krb5 token minimum length\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89542", "url": "https://ubuntu.com/security/CVE-2026-89542", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89547", "url": "https://ubuntu.com/security/CVE-2026-89547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Check svc pool percpu counter allocation __svc_create() initializes three per-pool percpu_counter stats and ignores every return value. On SMP, percpu_counter_init() fails when __alloc_percpu_gfp() cannot satisfy the allocation, leaving the failed counter with fbc->counters == NULL and its embedded raw_spinlock_t, list_head, and count never initialized. __svc_create() returns the half-constructed svc_serv to nfsd, lockd, or the NFS callback service anyway. Once that service is live, the hot-path increments in svc_xprt_enqueue(), svc_handle_xprt(), and svc_pool_wake_idle_thread() reach a counter whose backing pointer is NULL. The pointer is a per-cpu offset, so the access does not fault: it resolves to offset zero of the current CPU's per-cpu area and silently corrupts whatever variable lives there. A /proc/fs/nfsd/pool_stats read walks the same NULL per-cpu storage and returns garbage, and on CONFIG_DEBUG_SPINLOCK or lockdep it splats on the never-initialized lock. Creating the broken service requires a percpu allocation failure during RPC server startup, so it is reachable only by a local administrator under memory pressure or fault injection; a remote peer cannot induce the bad state on its own. Check each percpu_counter_init() return value in __svc_create() and fail when an allocation fails, unwinding the counters already set up in the current pool and in every pool initialized before it. A discrete percpu_counter_destroy() per counter at teardown frees each per-cpu allocation exactly once.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89548", "url": "https://ubuntu.com/security/CVE-2026-89548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: always drain cache_cleaner before destroying a cache_detail sunrpc_destroy_cache_detail() only cancels the global cache_cleaner delayed_work when cache_list is empty. During per-netns teardown cache_list is never empty because init_net's caches remain registered, so the cancel never fires. After unlink, the caller proceeds to cache_destroy_net() which kfrees the cache_detail while cache_clean() may still hold a dangling pointer to it. The result is a use-after-free: cache_dequeue() takes cd->queue_lock on freed memory, and cache_put() dereferences cd->cache_put as a function pointer from freed slab. Drop the list_empty guard so that cancel_delayed_work_sync() always runs, ensuring any in-flight cache_clean() completes before the cache_detail is freed. Re-arm the cleaner afterwards if other caches are still registered.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89550", "url": "https://ubuntu.com/security/CVE-2026-89550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division. Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload. Fix by adding a minimum-length check immediately after the existing upper-bound check: if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89551", "url": "https://ubuntu.com/security/CVE-2026-89551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89552", "url": "https://ubuntu.com/security/CVE-2026-89552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: params: fix charp corruption on allocation failure param_set_charp() stores charp parameters in allocated memory after slab is available, and releases the previous value when the parameter is updated. The previous value is released before the replacement allocation succeeds. If kmalloc_parameter() fails, the setter returns -ENOMEM with the parameter left as NULL. Failing zswap's compressor update before zswap is initialized can later trigger: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strcmp+0x10/0x30 Call Trace: zswap_setup+0x3b1/0x490 zswap_enabled_param_set+0x5b/0xa0 param_attr_store+0x93/0xe0 module_attr_store+0x1c/0x30 kernfs_fop_write_iter+0x116/0x1f0 Allocate and copy the replacement first, then replace the parameter value only after allocation succeeds.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89553", "url": "https://ubuntu.com/security/CVE-2026-89553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/gem: reserve the bo in the info ioctl around the vma lookup In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free. Spotted with the help of Opus 4.6.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89554", "url": "https://ubuntu.com/security/CVE-2026-89554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce, backup, join_id, token and msk from the saved cookie entry when rebuilding the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it does not restore local_id, even though the SYN path saved it. subflow_ulp_clone() then reads that uninitialized field and stores it as the joined subflow's address-ID. Because the request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale byte of a previously freed request socket, which an off-path peer can influence by sending concurrent MP_JOIN SYNs. This corrupts the path manager's id-based subflow bookkeeping for the connection. Restore subflow_req->local_id from the cookie entry, as done for the other fields.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89555", "url": "https://ubuntu.com/security/CVE-2026-89555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: reload header after pskb_may_pull() mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header. If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header. The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs: BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23 Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89557", "url": "https://ubuntu.com/security/CVE-2026-89557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: do overflow check for sb->bblog_shift in super_1_load() In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89559", "url": "https://ubuntu.com/security/CVE-2026-89559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Prevent integer overflow in __nd_label_validate() The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write. The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected. The check was safe when introduced by commit 4a826c83db4e (\"libnvdimm: namespace indices: read and validate\"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f (\"libnvdimm, label: add v1.2 nvdimm label definitions\") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89562", "url": "https://ubuntu.com/security/CVE-2026-89562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: fix hardware header length for NBMA tunnels ip6gre_tnl_link_config_route() accumulates the lower device's hardware header length into dev->hard_header_len whenever header_ops is set. This is incorrect for both users of header_ops. ip6gretap and ip6erspan have a fixed Ethernet hardware header length. For an NBMA ip6gre tunnel, ip6gre_header() creates only the GRE header, the optional FOU or GUE header, and the outer IPv6 header. The lower device header is headroom needed later, not part of the tunnel device's hardware header. Keep the lower device header in needed_headroom. Set hard_header_len to the tunnel header length only for ARPHRD_IP6GRE devices with header_ops, and leave the fixed Ethernet header length unchanged for tap and erspan devices.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89563", "url": "https://ubuntu.com/security/CVE-2026-89563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit() ip6_tnl_xmit() may need to expand headroom before it can push the outer IPv6 and optional encap headers. It currently does that with skb_realloc_headroom(), copies skb->sk ownership, consumes the original skb, and then continues processing with the replacement skb kept only in its local variable. That is safe only if the helper cannot fail afterwards. But this helper still has post-reallocation error exits. collect_md tunnels reject non-NONE encap after the replacement, and ip6_tnl_encap() can also fail later. In those cases the helper returns an error to its callers while the caller still only has the original skb pointer. Both ip6_tnl_start_xmit() and the IPv6 GRE paths free the caller skb on error, so they can end up freeing an skb that ip6_tnl_xmit() already consumed. Use skb_cow_head() instead. It provides the required headroom and writability without privately replacing the caller-owned skb, so later error returns cannot leave callers with a stale pointer. The Ethernet users, ip6gretap and ip6erspan, clear IFF_TX_SKB_SHARING and already call skb_cow_head() before entering ip6_tnl_xmit(). They do not rely on the removed skb_shared() reallocation. This also makes the IPv6 tunnel path consistent with ip_tunnel_xmit().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89569", "url": "https://ubuntu.com/security/CVE-2026-89569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: serialize security confirmation handling rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-80914", "url": "https://ubuntu.com/security/CVE-2026-80914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 (\"Bluetooth: ISO: hold sk properly in iso_conn_ready\"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-89573", "url": "https://ubuntu.com/security/CVE-2026-89573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: reject an array block whose value size is not the caller's array_block_check() can only compare the header against itself, so a block with value_size 4 and max_entries 1018 is internally consistent and passes. dm-cache keeps two arrays -- mappings at 8 bytes and hints at 4 -- and the roots for both live in the superblock. Point the mappings root at a hint block and __load_mappings() walks it through an info whose value size is 8, so element_at() strides 8 bytes over 4-byte entries and reaches offset 8160 of a 4096-byte block. get_ablock() and __shadow_ablock() are the two places that hold the block and the caller at once. Reject there when the two value sizes disagree. Arrays only ever read their own blocks, so this fires on crafted metadata only.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89574", "url": "https://ubuntu.com/security/CVE-2026-89574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm array: validate array block headers on read array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89575", "url": "https://ubuntu.com/security/CVE-2026-89575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm raid1: reserve space for NUL-terminator in build_constructor_string() Reserve space for the termination NUL after the maximum 20 decimal digits of a long long value to avoid buffer overflow in sprintf().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89576", "url": "https://ubuntu.com/security/CVE-2026-89576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89579", "url": "https://ubuntu.com/security/CVE-2026-89579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Harden bloom filter sizing and indexing on 32-bit kernels bloom_map_alloc() has two 32-bit-specific problems when the computed bitmap reaches the U32_MAX fallback case. First, BITS_TO_BYTES(U32_MAX) is evaluated with 32-bit arithmetic. The addition performed by DIV_ROUND_UP wraps, so the map allocates only the fixed-size bloom filter object while keeping bitset_mask == U32_MAX. Subsequent updates can then write past the allocated object. Second, fixing only the allocation size is not sufficient. The bloom hash is a u32, but set_bit() takes a signed long bit number and x86 test_bit() eventually feeds the index to variable_test_bit(long, ...). On 32-bit kernels, hashes in [0x80000000, U32_MAX] therefore become negative bit offsets. x86 bt/bts with a memory operand interpret those offsets relative to the supplied base, so a map with bitset_mask == U32_MAX can read or write before bloom->bitset even after allocating the full 512 MiB bitmap. Keep the U32_MAX fallback, but split each hash into a word pointer and an in-word bit number before calling test_bit() or set_bit(). The bitops argument is then always in [0, BITS_PER_LONG - 1], while BIT_WORD(h) still selects the intended word in the full bitmap. Compute the bitset size from (u64)bitset_mask + 1 before passing the final size to bpf_map_area_alloc(). This fixes the original under-allocation and keeps the allocated storage consistent with the addressable bitset. Exploitation note: local privilege escalation is possible on a 32-bit x86 kernel using the under-allocation bug from a binary with CAP_BPF.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89580", "url": "https://ubuntu.com/security/CVE-2026-89580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Disable preemption in __bpf_get_stack get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below. A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy_len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build_id path. The rcu_read_lock() taken here alone does not prevent this. It is only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call_rcu()) and does nothing to stop another task from reusing the entry. Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max_depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt_disable() also subsumes the buffer-lifetime guarantee the rcu_read_lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call_rcu() reclaim. [ changed Fixes: commit ]", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89582", "url": "https://ubuntu.com/security/CVE-2026-89582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix double free in bnx2x_init_firmware() error path bnx2x_init_firmware() frees bp->init_ops, bp->init_data and bp->init_ops_offsets in its error path without setting them to NULL. The cleanup function bnx2x_release_firmware() frees the same three pointers unconditionally, so if init_firmware fails and release_firmware is later called (e.g. from __bnx2x_remove or through the function state machine), all three are freed a second time. Set each pointer to NULL after kfree() in the error path so that the subsequent kfree(NULL) in bnx2x_release_firmware() is a safe no-op.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89583", "url": "https://ubuntu.com/security/CVE-2026-89583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix OOB read in eir_get_service_data() eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a \"field\" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89585", "url": "https://ubuntu.com/security/CVE-2026-89585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: auxdisplay: charlcd: cancel backlight work on registration failure With CONFIG_CHARLCD_BL_FLASH, charlcd_init() schedules bl_work before charlcd_register() calls misc_register(). If registration fails, the caller frees the charlcd object while delayed work still contains its address. Add charlcd_deinit() to cancel the delayed work and turn the backlight off. Use it for both registration rollback and normal unregistration.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89586", "url": "https://ubuntu.com/security/CVE-2026-89586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes ata_scsi_write_same_xlat() translates a SCSI WRITE SAME command with the UNMAP bit set into an ATA DATA SET MANAGEMENT TRIM command. The TRIM descriptor is built by ata_format_dsm_trim_descr() into the 2048-byte ata_scsi_rbuf staging buffer, and the number of bytes copied is compared against the logical sector size by the caller: \tsize = ata_format_dsm_trim_descr(scmd, trmax, block, n_block); \tif (size != len)\t\t/* len == sdp->sector_size */ \t\tgoto invalid_param_len; ata_format_dsm_trim_descr() clamps the copy length to ATA_SCSI_RBUF_SIZE (2048). On a device whose logical sector size exceeds that (e.g. a 4Kn device, where sector_size == 4096) the function can never return more than 2048, while the caller expects it to return sector_size. The comparison therefore always fails, so every TRIM is rejected with \"Parameter list length error\" and WARN_ON() splats on each attempt. TRIM / discard is thus completely broken on such devices. The descriptor was incorrectly sized from the logical sector size. A DSM TRIM payload is a list of 512-byte pages, each holding up to ATA_MAX_TRIM_RNUM (64) LBA Range Entries, and is independent of the logical sector size. The Block Limits VPD page already advertises a single such page as the maximum WRITE SAME length (65535 * ATA_MAX_TRIM_RNUM logical blocks), so the block layer never sends a request that needs more than one page. Emit exactly one 512-byte page, independent of the logical sector size, and transfer only that page (COUNT == 1). For a 512-byte-sector device this is unchanged; devices with larger logical sectors now work instead of failing every TRIM.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89587", "url": "https://ubuntu.com/security/CVE-2026-89587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: pfr_update: fix stack buffer overflow in query_capability() query_capability() copies four ACPI buffer objects returned by the firmware _DSM into fixed-size u8[16] fields in struct pfru_update_cap_info using memcpy with the firmware-supplied length: memcpy(&cap_hdr->code_type, elements[CAP_CODE_TYPE_IDX].buffer.pointer, elements[CAP_CODE_TYPE_IDX].buffer.length); The same pattern repeats for drv_type, platform_id, and oem_id. If the firmware returns buffer.length > 16 for any of these fields, memcpy writes past the destination array. struct pfru_update_cap_info is stack-allocated in pfru_ioctl(). Confirmed with KASAN on 7.2-rc6: three stack-out-of-bounds reports are generated when a DSM returns 64-byte buffers, with writes reaching 44 bytes past the end of cap_hdr's [64, 156) frame window into adjacent stack redzones. Introduce a helper pointer to out_obj->package.elements and use it to validate each buffer length against its destination field size before copying, returning -EINVAL if the firmware supplies an oversized buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89588", "url": "https://ubuntu.com/security/CVE-2026-89588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: GHES: fix ARM section length accounting after header In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89594", "url": "https://ubuntu.com/security/CVE-2026-89594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device The OMAP SSI driver uses a synthetic HSI controller device allocated via hsi_alloc_controller(), which does not go through the normal OF/platform device initialization path. As a result, the embedded struct device does not have a DMA mask initialized by default. After recent DMA API hardening changes, dma_map_sg() and related helpers now require a valid dma_mask to be present, otherwise the driver may crash or trigger warnings when attempting DMA mapping operations. Fix this by explicitly initializing the DMA mask for the SSI controller device and setting a 32-bit DMA mask, which matches the hardware capabilities.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89596", "url": "https://ubuntu.com/security/CVE-2026-89596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix off-by-one when saving/restoring non-PCI config space nv_suspend() and nv_resume() walk the non-PCI configuration space with \tfor (i = 0; i <= np->register_size/sizeof(u32); i++) which runs one iteration too many. saved_config_space is declared as \tu32 saved_config_space[NV_PCI_REGSZ_MAX/4]; and NV_PCI_REGSZ_VER3 is equal to NV_PCI_REGSZ_MAX (0x604), so on a VER3 device register_size/sizeof(u32) is exactly the array length and the last iteration addresses one element past the end. The element it lands on is np->name_rx[0..3]: saved_config_space[] is followed immediately by char name_rx[IFNAMSIZ + 3], and char needs no padding. Nothing observable is corrupted by that, because nv_request_irq() rewrites name_rx with sprintf() before it is ever passed to request_irq(). The bug is the out-of-bounds access itself, which UBSAN reports and which CONFIG_UBSAN_TRAP=y turns into a trap that aborts the running kernel code, plus an MMIO read and, on resume, an MMIO writel() to base + 0x604, one dword past the range the driver mapped: \tnp->base = ioremap(addr, np->register_size); VER1 and VER2 devices stay inside the array, but they too get the stray read and the stray write one dword past their own window. Caught by UBSAN on an Apple Macmini3,1 (MCP79) during a deep S3 cycle. The splat below is trimmed: the build path in the file name, the CPU and taint lines, the Workqueue line, the \"?\" hint frames, and the frames below device_suspend are all cut. The kernel was tainted, with an out-of-tree nouveau and CPU_OUT_OF_SPEC; forcedeth itself was the stock module. UBSAN: array-index-out-of-bounds in drivers/net/ethernet/nvidia/forcedeth.c:6225:25 index 385 is out of range for type 'u32 [385]' Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x54/0x59 __this_module+0xe398c/0xe9010 [forcedeth] pci_pm_suspend+0x80/0x170 dpm_run_callback+0x51/0x160 device_suspend+0x1a2/0x4a0 ... Both loops are hit. UBSAN reports each source location only once per module load (__ubsan_handle_out_of_bounds() calls suppress_report(), which does test_and_set_bit(REPORTED_BIT, ...) on the struct source_location), so the two splats land in the first S3 cycle after the module is loaded and later cycles are silent even though the access still runs off the end every time. In that first cycle line 6225 is reported from pci_pm_suspend and line 6240 from pci_pm_resume. The same off-by-one was fixed in nv_get_regs() by commit ba9aa134287f (\"forcedeth: fix buffer overflow\") in 2012; these two loops were missed. The suspend and resume side was reported on LKML in September 2013 by Marc Weber, with the same analysis and the same one-character fix, but the patch was attached rather than sent inline and the thread ended there. Use < instead of <=, which saves and restores exactly register_size bytes.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89597", "url": "https://ubuntu.com/security/CVE-2026-89597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: unregister connector callback on init failure uvesafb_init() registers the v86d connector callback before registering the platform driver. If platform_driver_register() fails, the function returns the error directly and leaves the connector callback registered. The later platform-device failure path already unregisters the callback. Add the same cleanup before the final return when platform-driver registration fails. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89598", "url": "https://ubuntu.com/security/CVE-2026-89598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: ssd1307fb: defer I2C transfers from damage callbacks The fbdev damage callbacks may run from fbcon while printk has disabled preemption. They currently update the display synchronously, which enters the sleeping I2C transfer path from atomic context. A complete report from an RK3566 system follows: [ 258.129004] watchdog: watchdog0: watchdog did not stop! [ 258.129067] BUG: scheduling while atomic: systemd/1/0x00000003 [ 258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2 spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2 stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables x_tables autofs4 [ 258.129215] Preemption disabled at: [ 258.129216] [] vprintk_emit+0x11c/0x340 [ 258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G C 6.6.0-rc5-rockchip-rk356x #4 [ 258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT) [ 258.129243] Call trace: [ 258.129245] dump_backtrace+0xa0/0x128 [ 258.129252] show_stack+0x20/0x38 [ 258.129256] dump_stack_lvl+0x60/0xb0 [ 258.129265] dump_stack+0x18/0x28 [ 258.129269] __schedule_bug+0xa0/0xc8 [ 258.129274] __schedule+0x9ac/0xd30 [ 258.129279] schedule+0x60/0x100 [ 258.129282] schedule_timeout+0x194/0x338 [ 258.129289] rk3x_i2c_xfer_common.isra.0+0x384/0x498 [ 258.129296] rk3x_i2c_xfer+0x20/0x60 [ 258.129300] __i2c_transfer+0x194/0x648 [ 258.129308] i2c_transfer+0x9c/0x130 [ 258.129313] i2c_transfer_buffer_flags+0x64/0x98 [ 258.129318] ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb] [ 258.129334] ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb] [ 258.129343] soft_cursor+0x13c/0x210 [ 258.129350] bit_cursor+0x2dc/0x550 [ 258.129354] fbcon_cursor+0xec/0x108 [ 258.129359] hide_cursor+0x44/0xc8 [ 258.129365] vt_console_print+0x398/0x3b0 [ 258.129370] console_flush_all.isra.0+0x17c/0x410 [ 258.129377] console_unlock+0x4c/0x100 [ 258.129382] vprintk_emit+0x1c8/0x340 [ 258.129386] vprintk_default+0x40/0x58 [ 258.129389] vprintk+0xb8/0xd0 [ 258.129392] _printk+0x68/0x98 [ 258.129398] watchdog_release+0x170/0x230 [ 258.129404] __fput+0xbc/0x288 [ 258.129409] __fput_sync+0x58/0x70 [ 258.129413] __arm64_sys_close+0x40/0x90 [ 258.129419] invoke_syscall+0x4c/0x118 [ 258.129426] el0_svc_common.constprop.0+0x48/0xf0 [ 258.129432] do_el0_svc+0x24/0x38 [ 258.129437] el0_svc+0x48/0x100 [ 258.129443] el0t_64_sync_handler+0xc0/0xc8 [ 258.129448] el0t_64_sync+0x190/0x198 [ 258.573087] ------------[ cut here ]------------ [ 258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count()) [ 258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871 preempt_count_sub+0x9c/0x148 [ 258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1 ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine v4l2_vp ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89599", "url": "https://ubuntu.com/security/CVE-2026-89599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: panel-dsi-cm: initialize lock before registering display dsicm_probe() registers the display before initializing ddata->lock. Once omapdss_register_display() publishes the display, another consumer can reach a dsicm callback that takes this mutex while it is still uninitialized. Initialize the mutex before registering the display so the published callbacks always see a valid lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89604", "url": "https://ubuntu.com/security/CVE-2026-89604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Rate limit statfs() handler Ravi reports that statfs() may be called by unprivileged users on the efivarfs mount point, which may result in a flood of calls to the QueryVariableInfo() runtime service. These calls are disproportionately costly on x86 systems where the variable store is backed by SMM, as each SMM entry requires a rendez-vous of all the CPUs. So rate limit the calls to QueryVariableInfo() at twice per second, and return the most recently obtained value for calls that are elided.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89605", "url": "https://ubuntu.com/security/CVE-2026-89605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: release message context on send failure ecryptfs_send_message_locked() moves a message context from the free list to the allocated list before sending the request to the userspace daemon. If ecryptfs_send_miscdev() fails, the context is left on the allocated list and cannot be reused. Move it back to the free list on failure and clear the caller's pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89606", "url": "https://ubuntu.com/security/CVE-2026-89606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject too-small tag 70 packets ecryptfs_parse_tag_70_packet() subtracts fixed metadata fields from the parsed packet body size to derive the encrypted filename size. A malformed packet with a body smaller than those fixed fields can underflow that size calculation. Reject tag 70 packets before the subtraction unless the body contains the signature, cipher code, and at least one byte of encrypted filename data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89607", "url": "https://ubuntu.com/security/CVE-2026-89607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes: 1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct. 2. memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat. Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES. The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check. Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant. [tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89608", "url": "https://ubuntu.com/security/CVE-2026-89608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: pass packet set buffer size to parser ecryptfs_parse_packet_set() receives a pointer into the file header, but it calculates the remaining packet buffer size from PAGE_SIZE - 8. For version 1 headers the packet set starts later in the header, so this can overstate the available buffer. Pass the actual packet set buffer length from the caller and calculate per-packet limits from the remaining bytes in that buffer. Recompute the remaining length after consuming a tag 3 packet before parsing the following tag 11 packet.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89609", "url": "https://ubuntu.com/security/CVE-2026-89609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ecryptfs: hold msg ctx list lock when cleaning daemon queue ecryptfs_exorcise_daemon() drops queued messages from a dying daemon without holding ecryptfs_msg_ctx_lists_mux, but ecryptfs_msg_ctx_alloc_to_free() requires that lock. Take the list lock while moving the queued contexts back to the free list to avoid racing with other global msg ctx list users.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89615", "url": "https://ubuntu.com/security/CVE-2026-89615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound page_lcns[] index by the log record The copy_lcns loop and the redo shorten loop index page_lcns[] at j + i, where i runs up to the log record's lcns_follow. That count is checked only against the record's own length, not the target entry, so check_dp_table() (which validates the entry's lcns_follow) does not cover it: the copy_lcns entry may even be freshly allocated after that check, and find_dp() bounds j but not i. A crafted record thus overflows page_lcns[] of an otherwise valid entry. Add dp_range_ok() and reject, before each loop, any record whose run does not fit the entry. These are the only two page_lcns[] accesses indexed by the record rather than the entry, so together with the entry validation every access is now bounded. [almaz.alexandrovich@paragon-software.com: original patch contained changes to the problem already handled, applied partly]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89616", "url": "https://ubuntu.com/security/CVE-2026-89616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89617", "url": "https://ubuntu.com/security/CVE-2026-89617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate dirty page table on log replay Each DIR_PAGE_ENTRY ends in a page_lcns[] array whose length is the on-disk lcns_follow field. check_rstbl() validates the table bookkeeping but never checks that this array fits in the entry, so a crafted lcns_follow lets the v0->v1 conversion memmove and later replay passes run off the entry. Add check_dp_table() to reject, right after check_rstbl(), any entry larger than its size claims via struct_size() (the same expression used to allocate these entries, so the check is overflow-safe by construction). All consumers can then trust lcns_follow as the real capacity. This covers every page_lcns[] access whose index is bounded by the entry itself (the conversion memmove, the HotFix store via find_dp(), and the self-bounded scan loops). Accesses whose index comes from the log record need a separate bound and are handled in a follow-up patch.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89618", "url": "https://ubuntu.com/security/CVE-2026-89618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Initialize ei->children and ei->list in init_ei() eventfs_create_dir() allocates the eventfs_inode and initializes it with init_ei(). But this does not initialize the eventfs_inode list_heads. If the eventfs_create_dir() fails due to memory pressure, it will call free_ei() before it initialized the lists, and that checks to make sure the eventfs_inode has no children. But because the list wasn't initialized, it will give a false warning. Fix it by moving the list initialization into init_ei(). [ Rewrote change log ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89621", "url": "https://ubuntu.com/security/CVE-2026-89621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: mcp2221: validate report size in mcp2221_raw_event() mcp2221_raw_event() never validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path. Add a minimum size check at entry and validate that the source range fits within the received report before the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89626", "url": "https://ubuntu.com/security/CVE-2026-89626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix field sysfs group cleanup on failure hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89627", "url": "https://ubuntu.com/security/CVE-2026-89627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: free buffered reports when destroying device roccat_report_event() duplicates each report with kmemdup() and stores the allocation in a circular-buffer slot. The allocation is released only when that slot is reused. The device destruction paths free struct roccat_device without releasing reports still stored in cbuf[]. This makes those allocations unreachable and leaks up to ROCCAT_CBUF_SIZE report buffers per device. Add a small destructor that frees every buffered report before freeing the device, and use it in both paths that can destroy a registered device.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89628", "url": "https://ubuntu.com/security/CVE-2026-89628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: picolcd: clamp eeprom debugfs read to bytes actually received picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte supplied by the device in its REPORT_EE_DATA reply -- clamped only to the caller's read() count: \tret = resp->raw_data[2]; \tif (ret > s) \t\tret = s; \tif (copy_to_user(u, resp->raw_data+3, ret)) It never checks resp->raw_size, the number of bytes picolcd_raw_event() actually copied into the 64-byte raw_data[] of the kmalloc'd struct picolcd_pending. A device (or a spoofed picoLCD) returning a length byte of 0xff, read with a count >= 255, makes copy_to_user() read past raw_data[] into adjacent slab memory and return it to userspace through the debugfs \"eeprom\" file: \tBUG: KASAN: slab-out-of-bounds in _copy_to_user \tRead of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd] The debug-dump path in the same file already validates the device length byte against the received size before trusting it; this read does not. The file is created S_IRUSR (root-only) and a crafted device is needed, so it is neither unprivileged- nor remotely-triggerable. Clamp the copy length to resp->raw_size - 3 (the payload actually received, minus the 3-byte header), floored at 0 for short replies.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89634", "url": "https://ubuntu.com/security/CVE-2026-89634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix ALIGN() overflow in symlink_data() error context loop The check added by commit 7d9a7f1f96cd (\"smb/client: fix possible infinite loop and oob read in symlink_data()\") compared the post-ALIGN length against the remaining buffer, but ALIGN() itself can overflow: for ErrorDataLength near UINT32_MAX (e.g. 0xFFFFFFF9), ALIGN(x, 8) wraps to 0, so the subsequent bounds check passes, and the loop advances by zero bytes leaving 'p' pointing into stale data. Fix by checking the raw ErrorDataLength against the remaining space before applying ALIGN(), then checking again after. Since raw_len is bounded by the buffer, raw_len + 7 cannot overflow, so the second check is an exact post-alignment bounds guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89636", "url": "https://ubuntu.com/security/CVE-2026-89636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: clear ce->tgthint in free_tgts() When free_tgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cache_dfs_tgt structures. If ce->tgthint is not reset before it is used later, it results in a use-after-free. Set ce->tgthint to NULL in free_tgts() after the elements are freed to reflect that no elements remain.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89640", "url": "https://ubuntu.com/security/CVE-2026-89640", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0 With len == 0 (clone to EOF), the effective length is computed as: len = src_inode->i_size - off; If off > i_size, this is a negative loff_t, corrupting the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request and inverting the range in filemap_write_and_wait_range(). The existing off >= i_size check fires only after the ioctl has already been sent. Snapshot i_size_read() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > src_size with -EINVAL. Treat off == src_size as a no-op, consistent with __generic_remap_file_range_prep().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89643", "url": "https://ubuntu.com/security/CVE-2026-89643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: avoid dropping live tree ref on fsnotify rule autoremove audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. [PM: dropped unnecessary comment for line length reasons]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89645", "url": "https://ubuntu.com/security/CVE-2026-89645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: drop recovered reloc root refs on recovery failure During relocation recovery, each fs root gets a reference to its relocation root. If loading or adding a later root fails, or if the first transaction commit fails, btrfs_recover_relocation() jumps to out_unset before merge_reloc_roots() and clean_dirty_subvols(). put_reloc_control() drops the list-owned relocation root references, but it does not clear fs_root->reloc_root or drop the references owned by those pointers. Mount cleanup only drops them when BTRFS_FS_ERROR is set, so an error such as -ENOMEM while processing a later root can leave references behind. Keep temporary references to the fs roots associated during recovery. On failure, clear their reloc_root pointers and drop the corresponding references. Once the first transaction commit succeeds, drop only the temporary fs root references and let the normal merge and cleanup paths handle the relocation roots. Fault injection on a pending-relocation image confirmed the cleanup gap. With an injected first-commit failure, 25 fs roots had reloc_root set with fs_error=0. With this fix, the same failure path drops that count to 0 before mount fails.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89647", "url": "https://ubuntu.com/security/CVE-2026-89647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: do not repeat ceph_trim_dentries() if no progress possible ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately. The dir-lease walk made this worse. When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease. `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue. Fix this in three steps: - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is `false`. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via `STOP` at the first fresh lease). - Only return `-EAGAIN` from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead. - After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (`count==0`). There is no reason to keep retrying when we are not over the cap limit and made no progress. Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`. Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in `/proc/lock_stat` (5 minute capture): class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00 ----------------------- &mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 ----------------------- &mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 With this patch: class name con-bounces contentions waittime-min waittime-max waittime-total waittime-avg acq-bounces acquisitions holdtime-min holdtime-max holdtime-total holdtime-avg &mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27 ----------------------- &mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89649", "url": "https://ubuntu.com/security/CVE-2026-89649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound xattr value length in __build_xattrs() __build_xattrs() decodes the MDS-supplied xattr blob one attribute at a time. For each attribute it reads a 32-bit name length, advances past the name bytes, reads a 32-bit value length, records the value pointer, and advances past the value bytes. The two length fields are read with ceph_decode_32_safe(), but the value bytes themselves are advanced over with a bare \"p += len\" and no ceph_decode_need() check that \"len\" bytes remain in the blob. For every attribute except the last, the next iteration's ceph_decode_32_safe() on the following name length implicitly verifies that the previous value did not run past the blob end. The final attribute has no successor, so its decoded value length is never checked against the blob bounds. A malicious or compromised metadata server can set the last attribute's value length larger than the bytes actually present in the blob. The blob is a dedicated kvmalloc() allocation sized to the wire length (ceph_buffer_new() in ceph_fill_inode()). __set_xattr() records the oversized length in xattr->val_len verbatim, and a later getxattr(2) runs memcpy(value, xattr->val, xattr->val_len) into a user-supplied buffer, copying bytes past the end of the allocation back to user space. Impact: a malicious metadata server discloses adjacent kernel heap bytes to a local user via getxattr(2) on a CephFS file. Add the missing ceph_decode_need() so an out-of-bounds value length on the final attribute fails the decode and returns -EIO instead of being stored.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89650", "url": "https://ubuntu.com/security/CVE-2026-89650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound num_export_targets array for mds info v2/v3 ceph_mdsmap_decode() in fs/ceph/mdsmap.c reads num_export_targets from each per-mds info record and advances the decode cursor by num_export_targets * sizeof(u32) without first checking that many bytes remain. The only upper-bound check that catches a runaway cursor (*p > info_end) is gated on info_v >= 4, because info_end is left NULL for info_v 2 and 3. When the monitor sends an MDS map whose per-mds info version is 2 or 3 with an oversized num_export_targets, the cursor moves past the message front buffer and the later export-targets loop calls the unchecked ceph_decode_32() on out-of-bounds memory. A kernel client processes CEPH_MSG_MDS_MAP from its monitor session (net/ceph/mon_client.c dispatches it; fs/ceph/super.c routes it to ceph_mdsc_handle_mdsmap(), which sets end to the front buffer bound and calls ceph_mdsmap_decode()). A malicious or compromised monitor, or an on-path attacker on an unsigned/unencrypted messenger session, can therefore drive an out-of-bounds read in the client kernel; on x86_64 with KASAN it is reported as a slab-out-of-bounds read in ceph_mdsmap_decode(). The decoded values land in the internal info->export_targets[] array, so the consequence is a kernel out-of-bounds read, not an information leak to the attacker. Impact: a malicious or compromised Ceph monitor sending an MDS map with a per-mds info version of 2 or 3 and an oversized num_export_targets field triggers an out-of-bounds read in the CephFS client kernel. Add a ceph_decode_need() for the export-targets array before advancing the cursor, so the bound is enforced for every info_v >= 2, not only info_v >= 4. This mirrors the count-then-need idiom already used for m_data_pg_pools later in the same function. Compute the export-targets byte count with size_mul() and reuse that checked length when advancing the cursor, so the attacker-controlled num_export_targets multiplication fails closed on overflow rather than relying on the later kcalloc() guard.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89652", "url": "https://ubuntu.com/security/CVE-2026-89652", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().", "cve_priority": "critical", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89653", "url": "https://ubuntu.com/security/CVE-2026-89653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode MDSMap export_targets entries are monitor controlled. check_new_map() uses each entry as a bit number in a fixed stack bitmap, so a rank outside the protocol namespace can make set_bit() write past the end of the array. Reject ranks outside CEPH_MAX_MDS while decoding the map. Do not validate against possible_max_rank here because maps may legitimately reference ranks beyond a temporarily reduced max_mds.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89655", "url": "https://ubuntu.com/security/CVE-2026-89655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) \t MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89656", "url": "https://ubuntu.com/security/CVE-2026-89656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject buckets with mismatched CRUSH ids crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot. For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose(). Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89657", "url": "https://ubuntu.com/security/CVE-2026-89657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: validate OSD extent maps before cursor advance net/ceph/osd_client.c:osd_sparse_read() validates that the sparse-read data length matches the summed extent lengths, but it does not validate that each OSD-supplied extent is monotonic and lies inside the original request range. A malformed authenticated OSD reply can advertise a far-forward nonzero extent offset with a matching data length and make the client advance the message-data cursor beyond the request buffer. This reaches the BUG_ON(!*length) assertion in ceph_msg_data_next() from the client receive path. Impact: A malicious or compromised authenticated Ceph OSD peer can crash a kernel Ceph client via a malformed sparse-read reply. Reject sparse extent maps that overflow, move backwards, overlap, or extend outside the original sparse-read request before advancing the cursor. [ idryomov: perform sparse_extent_map_valid() check a bit earlier, in CEPH_SPARSE_READ_DATA_LEN instead of CEPH_SPARSE_READ_DATA_PRE state ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89662", "url": "https://ubuntu.com/security/CVE-2026-89662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89663", "url": "https://ubuntu.com/security/CVE-2026-89663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: revoke copy-notify stateids before dropping their reference Copy-notify stateids live in the s2s_cp_stateids IDR and on their parent stid's sc_cp_list, pinned by a single membership reference. _free_cpntf_state_locked() only unlinks an entry once its refcount reaches zero, so any revoke path that runs while a concurrent find_cpntf_state()/manage_cpntf_state() holder has elevated cs_count drops the reference without unlinking, leaving the entry discoverable with its membership reference already consumed. A second revoke or a laundromat tick then frees it while the reader still holds the pointer -- a KASAN-detectable use-after-free at the reader's nfs4_put_cpntf_state(). This affected all three revoke paths: - The parent-stid drain (nfs4_free_cpntf_statelist()) repeatedly called _free_cpntf_state_locked() on the first list entry; a holder that had bumped cs_count made it return early, so the next iteration re-decremented and burned the holder's reference. - OFFLOAD_CANCEL (manage_cpntf_state()) and laundromat expiry likewise used _free_cpntf_state_locked() and could drop 2->1 without unlinking. Add revoke_cpntf_state_locked(), which unhashes the entry from the IDR and sc_cp_list first (deferring the final free to any holder), and use it from all three revoke paths. The drain now walks with list_for_each_entry_safe() and revokes each entry unconditionally, so it terminates in one pass per entry regardless of cs_count. The unhash is gated on !list_empty(&cps->cp_list); the idr_remove() gate matters because idr_alloc_cyclic() may have recycled the so_id by then. Keep _free_cpntf_state_locked() for the reference-holder put path only, where a concurrent revoke may already have unlinked the entry (its list_del_init() then a no-op).", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89665", "url": "https://ubuntu.com/security/CVE-2026-89665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE The NFSv2 sattr decoder converts the wire useconds to nanoseconds in svcxdr_decode_sattr(): \tiap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC; tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds value such as 4294968 wraps to tv_nsec == 704. The corruption therefore happens during decode, before any proc function can inspect the value, and a later range check on tv_nsec would see an in-range result and accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply. NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return for a malformed time argument, and the check cannot move to the proc function the way the v3/v4 nsec range checks do. Guard the raw useconds before the multiplication and reject values greater than 1000000. useconds == 1000000 is kept: it is the Sun convention for \"set to the current server time\", and the in-tree Linux NFSv2 client emits it in both the atime and the mtime field for a plain touch / utimes(file, NULL) (see encode_sattr() and xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000 would turn that common operation into a hard decode failure for both SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap on ILP32, so the Sun convention value passes through safely. Only genuinely out-of-range values (> 1000000) are rejected. The atime and mtime guards are therefore symmetric. The decoder only applied the Sun convention in the mtime block, which clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a client puts 1000000 in the atime field but not in the mtime field, the atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET set, so the bogus value reached the filesystem. Apply the convention in the atime block as well, clearing ATTR_ATIME_SET so the server uses its current time and ignores the value. Only ATTR_ATIME_SET is cleared there. The mtime block keeps its existing behavior, where 1000000 means \"set both atime and mtime to now\". [ cel: various tweaks, addenda, and clean-ups ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89666", "url": "https://ubuntu.com/security/CVE-2026-89666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC. Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created. tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89669", "url": "https://ubuntu.com/security/CVE-2026-89669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize copy-notify stateid before publishing it nfsd4_copy_notify() finished initializing the cpntf state after nfs4_alloc_init_cpntf_state() had already linked it into the s2s_cp_stateids IDR and the parent's sc_cp_list, with cs_count == 1 (the membership reference) and none held for the caller. A racing OFFLOAD_CANCEL (crafted cl_id == nn->s2s_cp_cl_id plus the guessable so_id) could reach manage_cpntf_state() and free the entry, turning the caller's subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid writes into use-after-free. The owning clientid was also only recorded after publication, so it could not gate an ownership check in that window. Record cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state() before nfs4_init_cp_state() publishes the entry, and return it with an extra reference. The caller reads the stateid under that reference and drops it with nfs4_put_cpntf_state(); on a late error the laundromat reaps the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89671", "url": "https://ubuntu.com/security/CVE-2026-89671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: gate nfs3 setacl by argp->mask nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set: nfs3svc_decode_setaclargs() if (args->mask & NFS_ACL) decode into acl_access if (args->mask & NFS_DFACL) decode into acl_default /* otherwise the pointer stays NULL (pc_argzero) */ nfsd3_proc_setacl() set_posix_acl(.., ACL_TYPE_ACCESS, argp->acl_access) set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default) set_posix_acl(idmap, dentry, type, NULL) is the VFS \"remove this ACL type\" operation. A NULL pointer that means \"the client did not send this arm\" is therefore indistinguishable from \"the client asked to remove this ACL\". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both. The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl. Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89672", "url": "https://ubuntu.com/security/CVE-2026-89672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: gate nfs2 setacl by argp->mask The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode. nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS \"remove this ACL type\" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFS_ACL silently strips the directory's default ACL; mask=0 strips both. This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89674", "url": "https://ubuntu.com/security/CVE-2026-89674", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use \"8 + len\" but xdr_encode_opaque() actually writes \"4 + xdr_align_size(len)\" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89680", "url": "https://ubuntu.com/security/CVE-2026-89680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file leak on inter-server COPY setup failure When nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns nfserr_offload_denied directly, bypassing the out: label where release_copy_files() would drop the nf_dst reference taken by nfs4_preprocess_stateid_op(). Each failed inter-server COPY leaks one nfsd_file, pinning file/inode/dentry/vfsmount. Fix by setting status and jumping to out: instead of returning directly.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89684", "url": "https://ubuntu.com/security/CVE-2026-89684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix cpntf publish race in nfs4_init_cp_state nfs4_alloc_init_cpntf_state() published the new cpntf entry into the s2s_cp_stateids IDR (with cs_type set) in one s2s_cp_lock section, then took the lock again to list_add() it onto p_stid->sc_cp_list. In the gap the entry is reachable by so_id but cp_list is still {NULL,NULL} from kzalloc. A racing OFFLOAD_CANCEL (so_id is echoed to the client as cnr_stateid, so any NFSv4.2 client can drive it) reaches manage_cpntf_state() -> _free_cpntf_state_locked() and does list_del() on the zeroed list_head, oopsing the server. Fold the cs_type assignment and the list_add() into the same critical section as idr_alloc_cyclic(), so a concurrent lookup either misses the entry or sees a fully linked cp_list. INIT_LIST_HEAD() the entry after allocation and switch _free_cpntf_state_locked() to list_del_init() so a stale unlink is a no-op. nfs4_init_copy_state() passes NULL p_stid and skips the list_add, preserving NFS4_COPY_STID semantics.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89686", "url": "https://ubuntu.com/security/CVE-2026-89686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation revoke nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering the BUG_ON. This race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall. When the first client doesn't respond to the recall, the laundromat revokes it. A concurrent LAYOUTGET from any client using the delegation stateid hits the race window. Fix this by taking fi_lock around the fi_deleg_file read in the SC_TYPE_DELEG path, matching the locking discipline of the find_any_file() arm, and replacing the BUG_ON with a graceful error return that cleans up the partially-initialized layout stateid.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89690", "url": "https://ubuntu.com/security/CVE-2026-89690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: defer vfree of compound ops to fix rpc_status UAF The rpc_status netlink dumpit walks every in-flight svc_rqst under rcu_read_lock and, for NFSv4 requests, reads opnums out of args->ops[]. But args->ops is a separate vmalloc buffer freed synchronously by vfree() in nfsd4_release_compoundargs() at the end of every compound. The dumpit's rcu_read_lock pins the svc_rqst struct itself (freed via kfree_rcu), but nothing defers the vfree of the ops buffer across the RCU grace period. A concurrent compound completion can therefore free the buffer while the dumpit is reading it — a use-after-free on vmalloc memory. The trailing seqcount recheck (smp_load_acquire of rq_status_counter) cannot undo a load that already retired against freed memory. Fix by replacing vfree(args->ops) with kvfree_rcu_mightsleep(), which defers the free until after an RCU grace period. This makes the existing rcu_read_lock in the dumpit sufficient to protect the read. The tradeoff is that completed compound ops buffers (up to 200 * sizeof(struct nfsd4_op)) persist in memory slightly longer, across one grace period, before being reclaimed.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89691", "url": "https://ubuntu.com/security/CVE-2026-89691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: clear opcnt on compound arg release to prevent OOB read nfsd4_release_compoundargs() resets args->ops to the inline iops[8] array when the dynamically-allocated ops buffer is freed, but leaves args->opcnt at its original value (which can be up to 200 for NFSv4.1+ compounds). If rq_status_counter is stuck at an odd value (which can happen when nfsd_dispatch() hits an error path after setting it odd), the RPC status dumpit handler reads min(opcnt, 16) entries from args->ops[]. Since iops only has 8 elements and is the last field in struct nfsd4_compoundargs, reading indices 8-15 accesses adjacent slab memory and leaks it to userspace via netlink. Zero opcnt unconditionally in nfsd4_release_compoundargs() so stale compound metadata is never exposed through the status interface. [ cel: Remove the kvfree_rcu_mightsleep() sleep from the exposure window ]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89694", "url": "https://ubuntu.com/security/CVE-2026-89694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: check client ownership when cancelling a copy-notify stateid On the OFFLOAD_CANCEL path (clp != NULL), manage_cpntf_state() freed the target cpntf state without checking ownership. The lookup key st->si_opaque.so_id is allocated cyclically (guessable) and the embedded clientid is the fixed per-net nn->s2s_cp_cl_id, so any authenticated NFSv4.2 client could cancel and free another client's copy-notify stateid. Compare the creating clientid recorded in state->cp_p_clid against the requesting client's cl_clientid and return nfserr_bad_stateid on a mismatch instead of freeing the entry.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89696", "url": "https://ubuntu.com/security/CVE-2026-89696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref When CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return success with fh_dentry and fh_export both NULL if fh_verify() returns nfserr_stale and putfh->no_verify is true. The NFSD4_FH_FOREIGN flag is set, but the compound dispatch loop only uses this flag to bypass the nfserr_nofilehandle check -- it does not prevent subsequent ops from running with a NULL fh_dentry. A remote client can exploit this by crafting a COMPOUND that includes an inter-SSC COPY (which causes check_if_stalefh_allowed() to set no_verify=true on the saved PUTFH) with an additional op inserted between the source PUTFH and SAVEFH. For example, SETATTR calls fh_want_write() which dereferences fh_export->ex_path.mnt without calling fh_verify() first, causing a NULL pointer dereference in the nfsd kthread. Fix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set and fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow) and ops with ALLOWED_WITHOUT_FH (which don't need a resolved filehandle) may proceed. All other ops receive nfserr_stale, per RFC 7862 Section 15.2.3 which specifies that foreign filehandle validation is deferred to the consuming operation and NFS4ERR_STALE returned at that point.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89697", "url": "https://ubuntu.com/security/CVE-2026-89697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: add fh_want_write() for early-verified SETATTR in nfsd_proc_setattr() The BOTH_TIME_SET branch calls fh_verify() early so setattr_prepare() can inspect the dentry. This causes nfsd_setattr() to skip fh_want_write(), so notify_change() runs without a mount write reference. Add the missing fh_want_write() call after the early fh_verify().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89699", "url": "https://ubuntu.com/security/CVE-2026-89699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89702", "url": "https://ubuntu.com/security/CVE-2026-89702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: size fh_verify server sockaddr slot by xpt_locallen The nfsd_fh_verify and nfsd_fh_verify_err tracepoints declare the server sockaddr slot sized by xpt_remotelen but fill it from xpt_local using xpt_locallen: TP_STRUCT__entry( ... __sockaddr(server, rqstp->rq_xprt->xpt_remotelen) ... ) TP_fast_assign( ... __assign_sockaddr(server, &rqstp->rq_xprt->xpt_local, rqstp->rq_xprt->xpt_locallen); ... ) When xpt_locallen exceeds xpt_remotelen, __assign_sockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xpt_locallen < xpt_remotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers. The write-past-end case is reachable on NFS/UDP. svc_xprt_set_remote() is only called from svc_tcp_accept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svc_create_socket() for UDP calls only svc_xprt_set_local(), so xpt_remotelen stays 0 for the xprt's lifetime. Every fh_verify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xpt_local into a zero-byte slot. The other NFSD tracepoints that record the server address (NFSD_TRACE_PROC_CALL_FIELDS, NFSD_TRACE_PROC_RES_FIELDS, SVC_RQST_ENDPOINT_FIELDS) already size the server slot by xpt_locallen; nfsd_fh_verify and nfsd_fh_verify_err were the only exceptions. Fix by sizing the server slot with xpt_locallen so the declared slot matches the copy length. The client slot and its assignment already agree on xpt_remotelen and are left untouched.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89704", "url": "https://ubuntu.com/security/CVE-2026-89704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into \"since\" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling \"since\", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89706", "url": "https://ubuntu.com/security/CVE-2026-89706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89707", "url": "https://ubuntu.com/security/CVE-2026-89707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release path refs on follow_down() error nfsd_cross_mnt() initializes a local struct path with mntget() and dget() before calling follow_down(). On a negative return the error arm jumps to out without releasing those references: err = follow_down(&path, follow_flags); if (err < 0) goto out; follow_down() never drops the caller's entry-time refs on any error sub-case; for example a pre-cross d_manage() failure leaves path untouched, so the mntget()/dget() taken on entry survive the call. Every other early-exit arm in nfsd_cross_mnt() (other-namespace return, IS_ERR(exp2), and the success tail after the swap) already calls path_put(&path); the err < 0 arm is the lone omission. The leak inflates mnt_count and d_count on each failed cross-mount, blocking umount and pinning dentries against the shrinker, and is reachable by any authenticated NFS client through nfsd_lookup_dentry or the NFSv4 READDIR encode path. Fix by calling path_put(&path) before the goto out in the err < 0 arm so the entry-time refs are released on all follow_down() error returns.", "cve_priority": "high", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89710", "url": "https://ubuntu.com/security/CVE-2026-89710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget path When the server returns a new layout stateid while a valid one is still held, pnfs_layout_process() calls pnfs_mark_matching_lsegs_return() on the on-stack free_me list and jumps to out_forget. Segments whose reference count drops to zero are unlinked from lo->plh_segs and moved to free_me by mark_lseg_invalid(); for an idle cached segment the layout header holds the only reference, so this happens on the first decrement. out_forget never drains free_me -- only the success path calls pnfs_free_lseg_list(). Commit 814b84971388 (\"pNFS/NFSv4: Fix a layout segment leak in pnfs_layout_process()\") added the drain; commit 08bd8dbe8882 (\"pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()\") removed it while switching the destination to lo->plh_return_segs, which is drained elsewhere. Commit fb700ef02676 (\"NFSv4.1: Simplify layout return in pnfs_layout_process()\") switched the destination back to free_me without restoring the drain. Restore the pnfs_free_lseg_list() call.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89711", "url": "https://ubuntu.com/security/CVE-2026-89711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 (\"nfsd: check d_can_lookup in fh_verify of directories\") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89712", "url": "https://ubuntu.com/security/CVE-2026-89712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock nfsd4_ssc_expire_umount() walks nn->nfsd_ssc_mount_list with list_for_each_entry_safe(ni, tmp, ...). For each expired entry it sets nsui_busy = true, drops nfsd_ssc_lock to run mntput() on the source vfsmount, then reacquires the lock to list_del + kfree the entry and continue iterating via the macro's saved tmp pointer. The nsui_busy flag protects the current ni from concurrent nfsd4_ssc_setup_dul() finders during the lock-drop window, but it does not pin tmp. Another nfsd RPC thread that fails its source- server mount and reaches nfsd4_ssc_cancel_dul() will, during that same window, take nfsd_ssc_lock, list_del + kfree its own ssc_umount item, and release the lock. If that item is the saved tmp of the expire walk, the next iteration dereferences a freed nfsd4_ssc_umount_item. Restart the walk from the head after the mntput() unlock window so no saved next pointer survives the lock-drop. The list is bounded by the number of active inter-server source mounts (typically small) and the expire delayed-work runs periodically rather than per-IO, so the restart is cheap.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89713", "url": "https://ubuntu.com/security/CVE-2026-89713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: check truncate permission under inode lock nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:19:00 UTC" }, { "cve": "CVE-2026-89720", "url": "https://ubuntu.com/security/CVE-2026-89720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ubifs: fix out-of-bounds read in signature length check ubifs_sb_verify_signature() bounds the on-disk ubifs_sig_node->len field before handing the signature payload to verify_pkcs7_signature(), but the check has the wrong sign: \tif (le32_to_cpu(signode->len) > snod->len + sizeof(struct ubifs_sig_node)) The signature bytes start sizeof(struct ubifs_sig_node) (UBIFS_SIG_NODE_SZ, 64 bytes) into the node, so the payload is at most \tsnod->len - sizeof(struct ubifs_sig_node) bytes long. Adding the header size instead of subtracting it accepts a declared length up to 2 * UBIFS_SIG_NODE_SZ larger than the node actually holds -- past the end of c->sbuf, which is vmalloc(c->leb_size). verify_pkcs7_signature() -> pkcs7_parse_message() -> asn1_ber_decoder() is then handed that inflated length and reads beyond the allocation while walking the DER headers. The node length comes straight from the mounted image, so a crafted signed UBIFS image reaches this via ubifs_read_superblock() before the signature is cryptographically checked. snod->len is guaranteed to be >= UBIFS_SIG_NODE_SZ by the node scanner (c->ranges[UBIFS_SIG_NODE].min_len == UBIFS_SIG_NODE_SZ), so the corrected subtraction cannot underflow. Legitimately signed images are unaffected: a correct superblock never declares a signature longer than the node it is embedded in.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89723", "url": "https://ubuntu.com/security/CVE-2026-89723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after truncation Shuangpeng Bai reported that KASAN detected a slab-out-of-bounds error in nilfs_direct_propagate() during testing. Analysis revealed that after truncating a file, a node block immediately below the B-tree root was not deleted. Instead, it remained in the B-tree node cache in a dirty state. The log writer subsequently detected this block and incorrectly invoked nilfs_direct_propagate() on it, which is designed to handle only data blocks in direct mapping. B-tree nodes in the cache are managed by virtual block numbers, and their logical keys typically exceed the range expected by direct mapping. Consequently, processing such a node as a direct mapping entry triggers a slab-out-of-bounds access. The root cause is that when a B-tree mapping collapses into a direct mapping during truncation, an intermediate node block pointed to by the root node is left behind as garbage instead of being explicitly deleted. This resolves the issue by adding a nilfs_btree_discard() operation to delete the remaining intermediate node block during the conversion. A 'deform' flag is added to the bop_delete interface to explicitly signal that the deletion is part of a mapping transformation. This allows the B-tree mapping implementation to perform the necessary cleanup and discarding of the residual node structure that would be otherwise be left orphaned after the transition.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89724", "url": "https://ubuntu.com/security/CVE-2026-89724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vicodec: fix out-of-bounds write in FWHT encoder vidioc_s_fmt_vid_out() sizes the encoder CAPTURE buffer from the compressed descriptor pixfmt_fwht, whose sizeimage_mult is 3: coded_w * coded_h * 3 + sizeof(struct fwht_cframe_hdr). fwht_encode_frame() encodes one plane per component, and an incompressible plane takes the FWHT_FRAME_UNENCODED path in encode_plane(), copying the plane verbatim. For a 4-component pixel format all four planes are full resolution (width_div == height_div == 1), so a frame that forces every plane through the unencoded fallback writes sizeof(struct fwht_cframe_hdr) + 4 * coded_w * coded_h bytes, overrunning the plane by coded_w * coded_h, which can result in corruption of adjacent kernel heap memory. Bump pixfmt_fwht.sizeimage_mult from 3 to 4, matching the largest components_num among the supported raw formats, so the capture buffer is always large enough for the unencoded fallback.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89725", "url": "https://ubuntu.com/security/CVE-2026-89725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cec: stm32: prevent out-of-bounds write on RX overflow stm32_rx_done() appends each received CEC byte to rx_msg.msg[] using rx_msg.len as the write index, incrementing it on every RXBR (receive-byte-ready) interrupt without checking it against the buffer size: \tcec->rx_msg.msg[cec->rx_msg.len++] = val & 0xFF; rx_msg.msg[] is a fixed CEC_MAX_MSG_SIZE (16) byte array in struct cec_msg, and rx_msg.len is only reset on RXACKE/RXOVR or after a completed message (RXEND). The number of bytes received before RXEND is decided by the remote CEC device (it sets EOM), not by the driver. A peer that keeps sending bytes without ending the message drives RXBR repeatedly, pushing rx_msg.len past 16 and writing peer-controlled bytes out of bounds into the surrounding memory. This is reachable in normal operation once the driver has probed and receiving is enabled, from the IRQ thread, without any local privilege. The length check in the CEC core runs on the consumer side, after the byte has been stored, so it does not prevent the overflow. Bound the index in the driver before the store, as the other platform CEC drivers already do (e.g. tegra_cec), dropping the excess bytes of an overlong frame. Found by static analysis tool CodeQL.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89726", "url": "https://ubuntu.com/security/CVE-2026-89726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series \"lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()\", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89729", "url": "https://ubuntu.com/security/CVE-2026-89729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89730", "url": "https://ubuntu.com/security/CVE-2026-89730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write The trailing byte path in altera_cvp_send_block() dereferences a u32 pointer even when only 1-3 bytes remain in the input buffer. If the buffer ends at a page or scatterlist boundary, this can read past the valid image data and fault. Copy the remaining bytes into a zero-initialized u32 before writing the final word so only valid bytes are read from the input buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89732", "url": "https://ubuntu.com/security/CVE-2026-89732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent deadlock during ep0 read loop Currently, ffs_ep0_read() holds ffs->mutex when it prepares to go to sleep waiting for an event. When no setup events are pending, it calls wait_event_interruptible_exclusive_locked_irq() with the mutex still held. The wait macro deliberately drops the waitqueue spinlock before sleeping but does not drop the mutex. If a userspace daemon is polling ep0 via read() and the gadget is asynchronously torn down via configfs (e.g., echo \"\" > UDC), a deadlock can occur: 1. The configfs teardown calls functionfs_unbind(), which queues a FUNCTIONFS_UNBIND event. 2. The daemon wakes up, consumes the event, and drops the mutex. 3. However, if the daemon loops and immediately issues another read() before exiting, it reacquires ffs->mutex and again goes into an interruptible sleep. 4. Meanwhile, functionfs_unbind() continues execution and attempts to acquire ffs->mutex to tear down ep0req. 5. The kernel deadlocks because the configfs thread is stuck in an uninterruptible sleep waiting for the mutex, while the userspace daemon is in an interruptible sleep holding the mutex forever because no more events will arrive. To fix this, we drop both the waitqueue spinlock and ffs->mutex before going to sleep, and use wait_event_interruptible_exclusive() instead. Upon waking up, we jump back to the `retry` label to safely reacquire the mutex and re-evaluate the state machine. By not sleeping with ffs->mutex held, we natively decouple gadget teardowns (which require the mutex) from userspace polling.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89733", "url": "https://ubuntu.com/security/CVE-2026-89733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind() In uvc_function_bind() error path, we use usb_ep_free_request which uses uvc->control_req but does not set it to NULL afterwards. Thus, uvc->control_req is a dangling pointer causing a UAF. Also we do not set the uvc->control_buf pointer to NULL after freeing it, which is another dangling pointer. Fix it by setting uvc->control_req to NULL after we run usb_ep_free_request() and uvc->control_buf to NULL after kfree. Do the same for uvc_function_unbind().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89735", "url": "https://ubuntu.com/security/CVE-2026-89735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: remove default configfs groups on teardown f_midi2_alloc_inst() creates default configfs child groups for the default endpoint and default block using configfs_add_default_group(), setting their internal refcount to 1. However, during function teardown in f_midi2_free_inst() or EP cleanup in f_midi2_ep_opts_release(), configfs_remove_default_groups() is never called, therefore never dropping the refcount and leaking struct f_midi2_ep_opts and f_midi2_block_opts. Add the missing configfs_remove_default_groups() in the afformentioned functions to free the structs properly.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89736", "url": "https://ubuntu.com/security/CVE-2026-89736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix use-after-free on sound card disconnect g_audio_cleanup() invokes snd_card_free_when_closed() to initiate sound card teardown and immediately frees the underlying struct snd_uac_chip context. However, snd_card_free_when_closed() returns asynchronously while ALSA control elements (kctls) remain open in userspace. When userspace control applications access or close these open file descriptors, kctl callbacks attempt to dereference kctl->private_data pointing to &uac->c_prm or &uac->p_prm within the freed uac structure, resulting in a use-after-free (UAF) memory corruption. Fix this issue by deferring the destruction of struct snd_uac_chip until all references to the ALSA sound card are released. Register a custom card->private_free callback (u_audio_card_free) during g_audio_setup() that frees uac and its associated playback/capture request and ring buffers only when the sound card reference count drops to zero.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89738", "url": "https://ubuntu.com/security/CVE-2026-89738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration. Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc. Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and work_struct are never initialized. This does not require a fault; a normal driver unbind can interleave with an already queued work item. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89740", "url": "https://ubuntu.com/security/CVE-2026-89740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: imx: serialize imx_uart_ports[] lifetime imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[] before uart_add_one_port() because console setup uses the table. The entry is not cleared when adding the port fails or after removal, leaving a dangling pointer. A sibling probe can register the shared console through that stale entry. This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a sibling UART, unbinding the console UART and rebinding the sibling. Keep the entry valid through uart_remove_one_port(), then clear it. Protect port addition and removal together with their table updates so sibling operations cannot interleave. Reject an occupied slot rather than clobbering an active port during a duplicate-line probe.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89741", "url": "https://ubuntu.com/security/CVE-2026-89741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"media: v4l2-dev: fix error handling in __video_register_device()\" This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The intentions of that patch were good, but it doesn't work. The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources. However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct. But the put_device() will already have freed the struct, so you end up in a double-free scenario. There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model. That is a massive job, and it is very unlikely that device_register will fail. So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89742", "url": "https://ubuntu.com/security/CVE-2026-89742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rapidio: mport_cdev: fix use-after-free in dma_req_free() dma_req_free() acquires buf_mutex through req->map, drops the mapping reference with kref_put(), and then dereferences req->map again to unlock the mutex. If kref_put() drops the last reference, mport_release_mapping() frees the mapping, and the subsequent mutex_unlock() dereferences a freed object. This is a use-after-free. Fix this by caching map and md before kref_put(), clearing req->map while holding buf_mutex, and using the cached md for mutex unlocking. The bug is reachable from userspace via the RapidIO mport character device interface.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89743", "url": "https://ubuntu.com/security/CVE-2026-89743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: bound the device-reported response length nsm_sendrecv_msg_locked() stores the virtqueue used-ring length reported by the NSM device into msg->resp.len without bounding it to the response buffer. A malicious or buggy backend can report a length larger than the response buffer; parse_resp_raw() then copies that many bytes out of the fixed buffer to user space, disclosing adjacent kernel heap (an out-of-bounds read). The request path already floors its length in fill_req_raw(); the response path lacks the symmetric check. Clamp the stored length to the size of the response buffer. Well-behaved devices report no more than the posted buffer size, so conforming traffic is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89744", "url": "https://ubuntu.com/security/CVE-2026-89744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 (\"device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()\").", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89746", "url": "https://ubuntu.com/security/CVE-2026-89746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free with same-name named triggers When two hist triggers on different events are registered with the same name=, the second one reuses the first as named_data. Both are added to tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(), because save_hist_vars() is called before event_trigger_register() while the named reuse is only detected later, in hist_register_trigger(). In the named-data branch hist_register_trigger() then frees the second histogram's hist_data via destroy_hist_data(), but never removes its tr->hist_vars list entry, leaving a dangling pointer and leaking the trace_array reference it holds. A later hist trigger that references a variable makes find_var_file() walk tr->hist_vars and dereference the freed hist_data. The bug is reproducible from userspace by writing three hist triggers to tracefs: cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger The third write panics the kernel: BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix by removing the hist_data from tr->hist_vars and releasing the trace_array reference in the named-data branch of hist_register_trigger() before freeing the hist_data.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89747", "url": "https://ubuntu.com/security/CVE-2026-89747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free in trace_pipe read on sub-buffer order change Writing to buffer_subbuf_size_kb calls ring_buffer_subbuf_order_set(), which frees every sub-buffer of the ring buffer, including the reader page, and replaces them with newly allocated ones. Readers of trace_pipe hold pointers into those pages. ring_buffer_peek() looks up an event under cpu_buffer->reader_lock but returns the event pointer after dropping the lock, and peek_next_entry() then calls ring_buffer_event_length() and ring_buffer_event_data() on it. If the sub-buffer order is changed in that window, the reader dereferences freed memory: BUG: KASAN: use-after-free in ring_buffer_peek+0x3e0/0x430 Read of size 1 at addr ffff88802a4cf010 by task syz-executor989/6002 Freed by: free_buffer_page kernel/trace/ring_buffer.c:398 [inline] ring_buffer_subbuf_order_set+0x1325/0x18e0 kernel/trace/ring_buffer.c:7444 buffer_subbuf_size_write+0x182/0x280 kernel/trace/trace.c:8221 Take trace_access_lock(RING_BUFFER_ALL_CPUS) around the order change. This is the lock trace_pipe readers already hold across their entire peek-and-print loop, so the swap can no longer race with a reader that is dereferencing a peeked event.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89749", "url": "https://ubuntu.com/security/CVE-2026-89749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash passing ERR_PTR to kthread_stop() event_test_stuff() calls kthread_run() and unconditionally passes the returned task_struct pointer to kthread_stop(). kthread_run() returns an error pointer such as ERR_PTR(-ENOMEM) when kthread creation fails, for example under memory pressure during the boot-time event self-test. kthread_stop() then dereferences the invalid pointer, crashing the kernel. Check the result of kthread_run() before passing it to kthread_stop(). Use WARN_ON() so that a failure to create the self-test thread does not go unnoticed, matching the ring-buffer self-test fix in commit 91542863abad (\"ring-buffer: Fix crash passing ERR_PTR to kthread_stop()\").", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89750", "url": "https://ubuntu.com/security/CVE-2026-89750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/user_events: Clear copied tracing state before fork duplication dup_task_struct() copies user_event_mm from the parent into the child, without grabbing a reference to it. user_event_mm_dup() should replace it, but it leaves that copied pointer unmodified if user_event_mm_alloc() fails. When the child exits, user_event_mm_remove() decrements a reference the child never owned, which ultimately frees user_event_mm, while the parent still as a stale pointer to it. This creates a UAF, which KASAN reports as: BUG: KASAN: slab-use-after-free in current_user_event_mm+0x51/0x1d0 Write of size 4 at addr ffff888005010d30 by task init/44 Call Trace: kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 current_user_event_mm+0x51/0x1d0 user_events_ioctl+0x82e/0x15c0 __x64_sys_ioctl+0x139/0x1c0 do_syscall_64+0xce/0x450 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 44: __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x180/0x3a0 user_event_mm_alloc+0x3c/0x1f0 current_user_event_mm+0x88/0x1d0 Freed by task 42: __kasan_slab_free+0x43/0x70 kfree+0x13a/0x390 process_one_work+0x696/0xf90 worker_thread+0x420/0xba0 The fix simply clears the copied pointer before any possible failure. In case of failure, the child then has nothing to free.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89751", "url": "https://ubuntu.com/security/CVE-2026-89751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix off-by-one in port I/O handling handle_in() and handle_out() in arch/x86/coco/tdx/tdx.c use: u64 mask = GENMASK(BITS_PER_BYTE * size, 0); GENMASK(h, l) includes bit h. For size=1 (INB), this produces GENMASK(8, 0) = 0x1FF (9 bits) instead of GENMASK(7, 0) = 0xFF (8 bits). The mask is one bit too wide for all I/O sizes. Fix the mask calculation.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89752", "url": "https://ubuntu.com/security/CVE-2026-89752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: memcg: stop reclaim when a limit update is superseded kernfs serializes file operations only per open file, so separate open files can update the same memory.high or memory.max file concurrently. Both handlers store the new limit before synchronous reclaim, but continue to use the writer's local target in the reclaim loop. If another writer raises or removes the limit, the first writer can continue reclaiming toward a stale target. For memory.max, this can leave the writer looping indefinitely once reclaim retries are exhausted. The OOM path sees sufficient margin under the current limit and returns true without killing, while the writer still compares usage against its stale target and records another OOM event. Check the current limit at the start of each reclaim iteration and stop if it no longer matches the writer's target. Reproducer: Populate a cgroup with anonymous memory and disable swapping. Lower memory.max from one open file, then restore it to \"max\" through another open file after the new limit becomes visible. Without the patch, the first writer remains blocked and repeatedly increments the OOM event counter. With the patch, it returns normally. This was not motivated by a reported production workload. We found it through automated randomized testing for our cgroup observability work and reduced it to the reproducer above.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89753", "url": "https://ubuntu.com/security/CVE-2026-89753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: \t0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 \ttask:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1]", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89756", "url": "https://ubuntu.com/security/CVE-2026-89756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch() migrate_pages_batch() unmaps each folio before moving it, and every unmap runs the mmu_notifier invalidate callbacks. On KVM hosts try_to_migrate() ends up in kvm_mmu_notifier_invalidate_range_start() -> tdp_mmu_zap_leafs(), which is expensive, so unmapping a large batch keeps the CPU busy for a long time. The loop already calls cond_resched(), but on PREEMPTION kernels that is a no-op, and involuntary preemption is not a Tasks-RCU quiescent state. A long batch therefore never reports a quiescent state, and the migrating task (e.g. kcompactd) becomes a Tasks-RCU holdout, stalling the Tasks-RCU grace period for minutes, which is common at Meta fleet: INFO: rcu_tasks detected stalls on tasks: 0000000055349ecc: .. nvcsw: 1157401/1157401 holdout: 1 idle_cpu: -1/56 task:kcompactd0 state:R running task Call Trace: tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread Use cond_resched_tasks_rcu_qs() so a quiescent state is reported even when cond_resched() does nothing. This has also been discussed at [1]", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89759", "url": "https://ubuntu.com/security/CVE-2026-89759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup when scanning task stacks Patch series \"mm/kmemleak: avoid soft lockup when scanning task\", v3. kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads. That prints the following message, depending on the workload+host configuration: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks Patches 2-3 let the scan loops stop early once a scan is interrupted. This patch (of 3): kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point. On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog: watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] scan_block kmemleak_scan kmemleak_scan_thread kthread A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section. Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task. The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop(). This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89761", "url": "https://ubuntu.com/security/CVE-2026-89761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix out-of-bounds write when null terminating a label vec aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries. aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger. len comes from the number of \"//&\" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required. The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with \"+ 1 for null terminator entry on vec\". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc().", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89762", "url": "https://ubuntu.com/security/CVE-2026-89762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix cred UAF caused by begin_current_label_crit_section() AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label. The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds. So in approximately the following scenario, things go wrong: 1. task begins with (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on for overriding 3. task calls override_creds(), which returns a pointer to the old subjective creds () 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with and drops 2 refs on 7. task leaves AppArmor LSM hook 8. task calls revert_creds() 9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to 10. another task drops the extra reference on that was used for overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.", "cve_priority": "low", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-89765", "url": "https://ubuntu.com/security/CVE-2026-89765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers/itimer: Zero-init old itimerval before copy to userspace On native sparc64, struct __kernel_old_timeval contains a four-byte hole after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit. put_itimerval() fills only the named fields in a stack-allocated __kernel_old_itimerval and copies the entire object to userspace, so getitimer() can expose the two padding holes. Zero-initialize the aggregate before assigning the fields so implicit padding is deterministic before it crosses the user/kernel boundary.", "cve_priority": "medium", "cve_public_date": "2026-09-11 20:20:00 UTC" }, { "cve": "CVE-2026-53313", "url": "https://ubuntu.com/security/CVE-2026-53313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)", "cve_priority": "low", "cve_public_date": "2026-06-26 20:17:00 UTC" }, { "cve": "CVE-2026-53113", "url": "https://ubuntu.com/security/CVE-2026-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix memory leaks in beacon template setup The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53102", "url": "https://ubuntu.com/security/CVE-2026-53102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req() mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked. Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path. Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 (\"wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error\") made a similar change. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43344", "url": "https://ubuntu.com/security/CVE-2026-43344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix die ID init and look up bugs In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, uncore_device_to_die() may return -1 when all CPUs associated with the UBOX device are offline. Remove the WARN_ON_ONCE(die_id == -1) check for two reasons: - The current code breaks out of the loop. This is incorrect because pci_get_device() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan. - Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error. Separately, when NUMA is disabled on a NUMA-capable platform, pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() to return -1 for all PCI devices. As a result, spr_update_device_location(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree. Fix this by using uncore_pcibus_to_dieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbep_pci2phy_map_init() to be added in spr_uncore_pci_init(). Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where NUMA is expected to be enabled.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-38205", "url": "https://ubuntu.com/security/CVE-2025-38205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1 [Why] If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated then they can lead to a divide by zero in downstream callers like CalculateVMAndRowBytes() [How] Initialize dummy value to a value to avoid divide by zero.", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-21817", "url": "https://ubuntu.com/security/CVE-2025-21817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: mark GFP_NOIO around sysfs ->store() sysfs ->store is called with queue freezed, meantime we have several ->store() callbacks(update_nr_requests, wbt, scheduler) to allocate memory with GFP_KERNEL which may run into direct reclaim code path, then potential deadlock can be caused. Fix the issue by marking NOIO around sysfs ->store()", "cve_priority": "low", "cve_public_date": "2025-02-27 20:16:00 UTC" }, { "cve": "CVE-2025-22127", "url": "https://ubuntu.com/security/CVE-2025-22127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in prepare_compress_overwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38621", "url": "https://ubuntu.com/security/CVE-2025-38621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: make rdev_addable usable for rcu mode Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.", "cve_priority": "low", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-22108", "url": "https://ubuntu.com/security/CVE-2025-22108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Mask the bd_cnt field in the TX BD properly The bd_cnt field in the TX BD specifies the total number of BDs for the TX packet. The bd_cnt field has 5 bits and the maximum number supported is 32 with the value 0. CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB fragments can approach or exceed the maximum supported by the chip. Add a macro to properly mask the bd_cnt field so that the value 32 will be properly masked and set to 0 in the bd_cnd field. Without this patch, the out-of-range bd_cnt value will corrupt the TX BD and may cause TX timeout. The next patch will check for values exceeding 32.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-80825", "url": "https://ubuntu.com/security/CVE-2026-80825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extra_tx_headroom, but forwarded frames are sent through ieee80211_8023_xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel: skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skb_panic+0x58/0x60 (P) skb_push+0x58/0x60 mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common] mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb] __mt76_tx_queue_skb+0x54/0xe8 [mt76] mt76_txq_schedule.part.0+0x204/0x478 [mt76] mt76_txq_schedule_all+0x50/0x80 [mt76] mt792x_tx_worker+0x68/0x100 [mt792x_lib] __mt76_worker_fn+0x84/0x150 [mt76] Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path. The same bug was fixed on mt7921 by commit 98c4d0abf5c4 (\"mt76: mt7921: don't assume adequate headroom for SDIO headers\"), but mt7925 was copied from mt7921 without the fix. Add the same guard here.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80835", "url": "https://ubuntu.com/security/CVE-2026-80835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Remove crypto_rng interface qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the \"rng\" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80922", "url": "https://ubuntu.com/security/CVE-2026-80922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Allow zero as a random number Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80837", "url": "https://ubuntu.com/security/CVE-2026-80837", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: don't queue packet path object notifications All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply. nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting packet, holding no mutex. Since commit 67cc570edaa0 (\"netfilter: nf_tables: coalesce multiple notifications into one skbuff\") that notification is no longer sent immediately. __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with commit_mutex held. Sending packets through a chain that references a depleted quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been freed: BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0 Write of size 8 at addr ff110001047183c0 by task poc/76 CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G W 7.2.0-rc6-kasan72rc6 #4 Call Trace: __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191 net/netfilter/nf_tables_api.c:1211 net/netfilter/nf_tables_api.c:8743) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain_inet nf_hook_slow __ip_local_out ip_push_pending_frames udp_send_skb udp_sendmsg __x64_sys_sendto Allocated by task 77: __alloc_skb (net/core/skbuff.c:704) __nft_obj_notify (include/net/netlink.h:1055 net/netfilter/nf_tables_api.c:8731) nft_quota_obj_eval (net/netfilter/nft_quota.c:68) nft_do_chain Freed by task 79: nf_tables_commit (include/linux/skbuff.h:1332 net/netfilter/nf_tables_api.c:10759 net/netfilter/nf_tables_api.c:11185) nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574) netlink_unicast netlink_sendmsg The buggy address belongs to the cache skbuff_head_cache of size 232 Queueing from the packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does. The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are still coalesced.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80838", "url": "https://ubuntu.com/security/CVE-2026-80838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: keep the last remote linked during FDB flush A non-nexthop FDB entry is expected to have at least one remote while it remains reachable through the FDB hash table. A filtered bulk flush violates this invariant when every remote matches: It unlinks the last remote in vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush() to destroy the parent FDB entry. An RCU reader can find the parent during this interval. first_remote_rcu() then applies list_entry_rcu() to the empty list head, producing an invalid remote pointer that the receive learning path can read from and write to. When a matching remote is the sole remaining remote, leave it linked and ask the caller to destroy the entire FDB entry. vxlan_fdb_destroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80839", "url": "https://ubuntu.com/security/CVE-2026-80839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject unrepresentable multicast TVLV offsets The network and transport header fields in struct sk_buff are 16-bit offsets from skb->head, and U16_MAX is reserved as the unset transport header value. batadv_tvlv_call_handler() sets both fields from a received multicast TVLV without checking whether the TVLV end is representable. If the end offset exceeds the field's range, skb_set_transport_header() truncates it so that the transport header precedes the network header. The negative difference is then returned by skb_network_header_len() as a large u32. batadv_mcast_forw_packet() consequently accepts an oversized multicast tracker and accesses memory beyond the skb data. Add skb_set_transport_header_careful(), an offset-aware counterpart to skb_reset_transport_header_careful(), which validates the final head-relative offset before assigning it. Use the new helper in batadv_tvlv_call_handler() and reject unrepresentable TVLVs before setting the network header.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80849", "url": "https://ubuntu.com/security/CVE-2026-80849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of current_key on reconnect to another peer tcp_inbound_ao_hash() is called before bh_lock_sock_nested() is taken, with only rcu_read_lock() held. On the fast path for established sockets, if the rnext_keyid sent by the peer differs from current_key->sndid, the key the peer asked for is looked up and stored in current_key. The lookup is inside the RCU read side, but current_key outlives it. When the socket is disconnected and connect() is called again for another peer, tcp_ao_connect_init() unlinks every key that does not match the new peer and frees it with call_rcu(). If current_key points at such a key, it is cleared to NULL. The fast path reads sk_state only once on entry, so a softirq that got into it while the socket was still established can update current_key after that loop has already run. The update is inside the RCU read side, so it comes before the call_rcu() callback, and once the callback frees the key, current_key is left pointing at freed memory. The next transmission picks that pointer up in tcp_get_current_key(). tcp_ao_transmit_skb() then reads the traffic key from the freed object, which is the use-after-free. Wait for one grace period before unlinking, and only if a key is going to be removed. By the time tcp_connect() runs the socket is already in TCP_SYN_SENT, and TCP_AO_ESTABLISHED does not contain TCPF_SYN_SENT, so a softirq entering after the wait cannot reach the fast path, and the ones already in it have finished. The existing NULL handling in the loop is then enough.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80850", "url": "https://ubuntu.com/security/CVE-2026-80850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix AO info use-after-free in tcp_ao_connect_init() tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling tcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that a key matches the peer and the bound device's current L3 master. tcp_ao_connect_init() later resolves the L3 master again and removes keys which do not match it. The socket lock does not stabilize the bound device's VRF membership. Detaching the device from its VRF between the initial validation and the L3-master calculation in tcp_ao_connect_init() can therefore make the validation succeed while initialization observes the default L3 domain and removes the only key. The subsequent AO lookup then fails, so the no-key path clears tp->ao_info and frees it directly. The receive path can find the socket in the ehash and load tp->ao_info under RCU before acquiring the socket lock. A reader which loaded the old pointer can thus continue into tcp_inbound_ao_hash() after the direct free. The issue was found during a static audit of TCP-AO object lifetime. An unprivileged reproducer in self-created user and network namespaces raced connect() with detaching a veth from its VRF while sending TCP-AO segments. It triggered the same KASAN report on two fresh boots: BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585/0x19f0 Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race/232 Call Trace: tcp_inbound_ao_hash+0x585/0x19f0 tcp_inbound_hash+0x677/0xa80 tcp_v4_rcv+0x1c3e/0x3ab0 Allocated by task 235: tcp_ao_alloc_info+0x43/0xf0 tcp_ao_add_cmd+0xdf7/0x13b0 do_tcp_setsockopt+0x168c/0x2640 Freed by task 235: kfree+0x1b8/0x550 tcp_connect+0x252/0x4f00 tcp_v4_connect+0x1114/0x1720 The bad address is 40 bytes inside the freed 128-byte object, matching the tcp_ao_info counters.key_not_found field. The two runs used 1000 attempts each, reached the no-key path 366 and 411 times, and produced one and two KASAN reports respectively. With this change, the same reproducer reached the no-key path 366 times in 1000 attempts without a KASAN report or oops. Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info, updates the socket memory and static-key accounting, and defers the free until after an RCU grace period. Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race makes the no-key state reachable during normal operation, so it is a handled condition rather than an impossible assertion. On panic_on_warn kernels the WARN would turn this handled race into a kernel panic.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80851", "url": "https://ubuntu.com/security/CVE-2026-80851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: serialize PDP context updates PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80774", "url": "https://ubuntu.com/security/CVE-2026-80774", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80755", "url": "https://ubuntu.com/security/CVE-2026-80755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject a permission value exceeding the class permission count perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image. security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write. The top-level symbol tables are validated this way; the nested per-class permission table is not. Reject a permission whose value exceeds nprim, which is already set when perm_read() runs. Well-formed policies are unaffected. [PM: tweak comment for line length]", "cve_priority": "low", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80864", "url": "https://ubuntu.com/security/CVE-2026-80864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS). Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths. Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.", "cve_priority": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80771", "url": "https://ubuntu.com/security/CVE-2026-80771", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: register input device after capabilities are set input_register_device() exposes the device to userspace immediately. In joycon_input_create() it was called before joycon_config_rumble() configures the FF_RUMBLE capability and the memless force-feedback device, so a concurrent EVIOCSFF could dereference a NULL dev->ff. Registering early also means the initial udev event lacks button and axis information, which can make input managers ignore the device. Move input_register_device() to the end of joycon_input_create(), after all capabilities, the IMU input device and the force-feedback callbacks have been configured.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2025-40074", "url": "https://ubuntu.com/security/CVE-2025-40074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: start using dst_dev_rcu() Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF. Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(), ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().", "cve_priority": "high", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-80820", "url": "https://ubuntu.com/security/CVE-2026-80820", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't livelock in scrub on a circular unlinked list LOLLM points out that online fsck can livelock if an unlinked inode list contains a loop. Use a bitmap to detect cycles.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74653", "url": "https://ubuntu.com/security/CVE-2026-74653", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU. It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked(). LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear. This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 (\"serial: 8250_dw: Avoid \"too much work\" from bogus rx timeout interrupt\") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80815", "url": "https://ubuntu.com/security/CVE-2026-80815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Use a private URB for the notification endpoint scarlett2_init_notify() used mixer->urb, which snd_usb_mixer_status_create() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the \"already in use\" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmd_done is left zeroed because it is initialised past that check and nowhere else. scarlett2_usb_init() then issues SCARLETT2_USB_INIT_1 and wait_for_completion_timeout() would crash adding to the zeroed wait.head. Use a separate URB in scarlett2_data, as done for FCP, and initialise cmd_done in scarlett2_init_private(). mixer.c was also freeing the URB in snd_usb_mixer_free() and resubmitting it in snd_usb_mixer_activate(), so scarlett2 must now do both: add scarlett2_cleanup_urb(), called from private_free and private_suspend, and a private_resume callback to re-establish the URB after resume. scarlett2_init_notify() is reached from there, and the URB kill path in scarlett2_notify() completes cmd_done, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinit_completion() to clear it. Also free the URB if the transfer buffer allocation fails, and both if usb_submit_urb() fails. Move scarlett2_init_notify() up next to scarlett2_cleanup_urb() so scarlett2_init_private() can reference it without a forward declaration.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80727", "url": "https://ubuntu.com/security/CVE-2026-80727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mce: Set up the polling timer before CMCI discovery I hit the following on one of my machines: mce: CPU0 BANK15 CMCI inherited storm ------------[ cut here ]------------ ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0 WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY RIP: 0010:debug_object_assert_init+0x18f/0x230 Call Trace: __mod_timer mce_timer_kick cmci_discover intel_init_cmci mce_intel_feature_init mcheck_cpu_init identify_cpu identify_boot_cpu arch_cpu_finalize_init start_kernel A second splat follows right after, from timer_setup() finding that same timer already queued: ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10 This is happening because CMCI storm detection is trying to modify the timer before latter was properly set up. Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(), and depends on neither the generic nor the vendor init. [ bp: Massage commit message. ]", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74602", "url": "https://ubuntu.com/security/CVE-2026-74602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer() In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0. This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if when freed: free_buffer_page() relies on this value. Align the value with the actual allocation size (buffer::subbuf_order).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74684", "url": "https://ubuntu.com/security/CVE-2026-74684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() The commit 4f61f133f354 (\"net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null\") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74483", "url": "https://ubuntu.com/security/CVE-2026-74483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't leak the user namespace when the mount fails bm_get_tree() takes a reference to the user namespace and hands it to get_tree_keyed() as the sget key. sget_fc() moves that reference into sb->s_fs_info and clears fc->s_fs_info, so from that point on the superblock owns it and bm_free() doesn't see it anymore. The superblock drops it in ->put_super(). But generic_shutdown_super() only calls ->put_super() from inside the if (sb->s_root) branch, so nothing releases it when bm_fill_super() fails: - The kzalloc_obj() failure leaves s_root NULL and the whole branch is skipped. - A simple_fill_super() failure in the file loop leaves s_root set, but s_op still points at simple_super_operations, which has no ->put_super(). bm_fill_super() installs s_ops only once simple_fill_super() returned success, and installing it earlier wouldn't help either because simple_fill_super() overwrites s_op. Either way vfs_get_super() calls deactivate_locked_super() and the reference is gone for good. binfmt_misc mounts are available in a user namespace and both the inode and the dentry cache are SLAB_ACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simple_fill_super() on demand and leak one user namespace per attempt. Drop the reference in ->kill_sb() instead, which runs unconditionally, the same way nfsd and rpc_pipefs release their keyed s_fs_info. That also stops ->put_super() from clearing s_fs_info while the superblock is still on @fs_supers. generic_shutdown_super() leaves it there on purpose so that sget_fc() keeps finding it until kill_sb() has run, but a NULL s_fs_info makes test_keyed_super() miss it, so a concurrent mount for the same user namespace skips the grab_super() wait and creates a second superblock for a namespace that is still being torn down.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80556", "url": "https://ubuntu.com/security/CVE-2026-80556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq. If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | atmci_interrupt | queue_work(system_bh_wq, | &host->bh_work) atmci_remove | atmci_cleanup_slot(...) | atmci_writel(host, ATMCI_IDR, ~0UL) | timer_delete_sync(&host->timer) | dma_release_channel(host->dma.chan) | free_irq(platform_get_irq(pdev, 0), host) | | atmci_work_func | // use host // devm resources released after | // remove returns, host is freed | | // use host (use-after-free) Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80576", "url": "https://ubuntu.com/security/CVE-2026-80576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject oversized IBs with per-ring packet limits On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74590", "url": "https://ubuntu.com/security/CVE-2026-74590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions The BPF verifier and the dynptr abstraction ensure that the memory space referenced by a dynptr remains valid. They do not, however, provide any guarantee that the contents of the memory are stable. kfuncs are expected to remain memory-safe even if concurrent modifications occur. bpf_get_fsverity_digest() didn't follow that: it could crash if arg->digest_size was concurrently modified. Fix that by using the known-good value hash_alg->digest_size instead. Also widen 'dynptr_sz' and 'out_digest_sz' to u64 to match the return type of __bpf_dynptr_size(). It doesn't appear that it can actually be more than INT_MAX currently (since __bpf_dynptr_data_rw() excludes file-based pointers), but the correct type might as well be used.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74592", "url": "https://ubuntu.com/security/CVE-2026-74592", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Instantiate file_truncate and path_truncate hooks Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74618", "url": "https://ubuntu.com/security/CVE-2026-74618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen(\"binfmt_misc\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74634", "url": "https://ubuntu.com/security/CVE-2026-74634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Prevent subbuf order change when resizing is disabled Because ring_buffer_subbuf_order_set() frees buffer pages, we can't allow it when resizing is disabled. A non-consuming reader is at risk of use-after-free (rb_advance_iter()). Return -EBUSY on resize_disabled, matching ring_buffer_resize() behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-64017", "url": "https://ubuntu.com/security/CVE-2026-64017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: pop cached request if it is usable When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use. Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway. The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-74677", "url": "https://ubuntu.com/security/CVE-2026-74677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: \telse \t\tschedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74710", "url": "https://ubuntu.com/security/CVE-2026-74710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: require at least 16 bytes of TX metadata AF_XDP accepts a TX metadata length as small as eight bytes, but every supported request needs the flags plus at least one eight-byte request field. Such short metadata also lets the kernel read beyond the registered area. Require 16 bytes rather than sizeof(struct xsk_tx_metadata) to preserve compatibility with applications that do not use launch-time metadata.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-68266", "url": "https://ubuntu.com/security/CVE-2026-68266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74440", "url": "https://ubuntu.com/security/CVE-2026-74440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Wait on external BO kernel fences in exec IOCTL Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68273", "url": "https://ubuntu.com/security/CVE-2026-68273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-80704", "url": "https://ubuntu.com/security/CVE-2026-80704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80711", "url": "https://ubuntu.com/security/CVE-2026-80711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: max17040: handle missing status supplier MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74484", "url": "https://ubuntu.com/security/CVE-2026-74484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74500", "url": "https://ubuntu.com/security/CVE-2026-74500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix stack info leak in RME Digiface status snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: \tbuf = kmemdup(data, size, GFP_KERNEL); \terr = usb_control_msg(dev, pipe, request, requesttype, \t\t\t value, index, buf, size, timeout); \tmemcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80689", "url": "https://ubuntu.com/security/CVE-2026-80689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map().", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74535", "url": "https://ubuntu.com/security/CVE-2026-74535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: avoid deadlocks in iso_sock_timeout iso_sock_timeout() takes lock_sock, so sync disabling the timer while holding that lock may deadlock. iso_sock_timeout() may also run concurrently with iso_conn_del(), which leads to UAF [Task 1] [Task hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del `------------> iso_conn_put caller frees hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL; /* UAF */ Fix the deadlock by removing the disable from the lock_sock sections. Move the timer from iso_conn to iso_pinfo to decouple it from iso_conn which may need to be freed in lock_sock section. Convert some of the clear_timer to disable_timer.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74536", "url": "https://ubuntu.com/security/CVE-2026-74536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix leaking sk after socket release iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80694", "url": "https://ubuntu.com/security/CVE-2026-80694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74543", "url": "https://ubuntu.com/security/CVE-2026-74543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: \tif (utn->work_pending) \t\treturn; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm \"syz-executor\", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80695", "url": "https://ubuntu.com/security/CVE-2026-80695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (sht3x) Fix unaligned accesses Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74565", "url": "https://ubuntu.com/security/CVE-2026-74565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: make nft_object rhltable per table The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup().", "cve_priority": "high", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-72111", "url": "https://ubuntu.com/security/CVE-2026-72111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reset register bounds before narrowing retval range in check_mem_access() When the BPF verifier processes a context load of an LSM hook return value, it calls __mark_reg_s32_range() to narrow the register to the hook's valid range. However, __mark_reg_s32_range() intersects the new range with the register's existing bounds using max_t()/min_t() rather than replacing them. If the destination register carries stale bounds from a prior instruction (e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than reality. The verifier then believes it knows the register's exact value, while at runtime the actual hook return value is loaded, creating a verifier/runtime mismatch that can be used to bypass BPF memory safety checks. The else branch already calls mark_reg_unknown() to reset register state before any narrowing. Apply the same reset in the is_retval path so stale bounds are cleared before __mark_reg_s32_range() intersects.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-80824", "url": "https://ubuntu.com/security/CVE-2026-80824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80826", "url": "https://ubuntu.com/security/CVE-2026-80826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80827", "url": "https://ubuntu.com/security/CVE-2026-80827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80828", "url": "https://ubuntu.com/security/CVE-2026-80828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Complete cleanup after system-resume errors A failed system resume can leave the card unusable until reboot. usb_audio_resume() jumps to err_out when snd_usb_pcm_resume() or snd_usb_mixer_resume() fails. The error path skips the out: block, which restores D0 and decrements chip->num_suspended_intf. The card stays in SNDRV_CTL_POWER_D3hot, so later control access blocks in snd_power_ref_and_wait(). USB core logs an interface resume callback error. It does not retry that callback, so a later callback cannot complete the skipped cleanup. usb_audio_suspend() increments num_suspended_intf before returning success. A system-resume callback must consume the system-suspend count even if a component resume fails. Otherwise, the stranded count skews later suspend and resume cycles. Do not apply this cleanup to runtime-resume errors. Runtime PM can retry -EAGAIN or -EBUSY without another suspend callback. The count must continue to describe that suspended interface. Other runtime-resume errors latch runtime_error in the PM core and do not cause an immediate callback retry. Both parts of the system-resume error path are longstanding. Commit 88a8516a2128a (\"ALSA: usbaudio: implement USB autosuspend\") introduced err_out past the D0 restore. Commit 862b2509d157c (\"ALSA: usb-audio: Fix inconsistent card PM state after resume\") later moved num_suspended_intf-- into the out: block. The error path now skips both operations. No third-party code is needed to reach the error path. snd_usb_mixer_resume() ends in snd_usb_mixer_activate(), which returns the result of usb_submit_urb() for devices that have a mixer status URB. Its mixer->private_resume hook can also fail through scarlett2_init_notify(). snd_usb_pcm_resume() issues a SET_CUR request to a UAC3 power domain. It can return -EPIPE or -EIO when the device stalls the request. Route a component error through out: only when system_suspend is nonzero. Continue to return runtime-resume errors through err_out. Later component resume stages remain skipped. The original error still reaches USB core. A later transfer can fail if the device did not recover. I reproduced the system-resume failure on an Audient iD14 MkI with an out-of-tree diagnostic mixer resume hook. An injected -EIO on the unpatched core left control readers in uninterruptible sleep in snd_power_ref_and_wait() until a reboot. With this patch, the same failure restored control access. A second system suspend and resume also succeeded after I disabled fault injection.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80829", "url": "https://ubuntu.com/security/CVE-2026-80829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): \tcount = snd_rawmidi_transmit(ep->ports[0].substream, \t\t\t\t &transfer_buffer[2], \t\t\t\t ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where \"if (count1 > count) count1 = count\" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb (\"ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80830", "url": "https://ubuntu.com/security/CVE-2026-80830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80921", "url": "https://ubuntu.com/security/CVE-2026-80921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: zero stale crypto bits When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80831", "url": "https://ubuntu.com/security/CVE-2026-80831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80832", "url": "https://ubuntu.com/security/CVE-2026-80832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix CCM AAD buffer underallocation The AAD buffer allocated in qce_aead_ccm_prepare_buf_assoclen() can be smaller than the length later programmed into the DMA scatterlist. The allocation size is currently calculated as: ALIGN(assoclen, 16) + MAX_CCM_ADATA_HEADER_LEN while the DMA length is set to: ALIGN(assoclen + adata_header_len, 16) Since ALIGN() does not distribute over addition, the allocation can be smaller than the DMA length. For example, when assoclen = 32 and adata_header_len = 2: allocation = ALIGN(32, 16) + 6 = 38 DMA length = ALIGN(32 + 2, 16) = 48 As a result, the QCE hardware can read beyond the allocated buffer while computing the CBC-MAC over the associated data. The extra bytes are folded into the authentication tag, resulting in an incorrect tag and causing CCM self-test failures such as: alg: aead: ccm-aes-qce encryption test failed (wrong result) on test vector 8 Fix the allocation by adding the maximum possible AAD header length before alignment: ALIGN(assoclen + MAX_CCM_ADATA_HEADER_LEN, 16) This guarantees that the allocated buffer is large enough for the fully padded AAD data for all supported header sizes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80840", "url": "https://ubuntu.com/security/CVE-2026-80840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80842", "url": "https://ubuntu.com/security/CVE-2026-80842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: fix use-after-free of a master VLAN's multicast context br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before stopping a VLAN's multicast context. That is the teardown handshake: lockless readers gate on the flag through br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so once it is cleared under the lock no reader can arm the context again. For a master VLAN the handshake never runs. __vlan_del() clears BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so br_multicast_toggle_one_vlan(masterv, false) returns early on !br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is never taken. br_vlan_put_master() then drains the context in br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a reader still inside rcu_read_lock() sees the context as enabled and re-arms it. The port and port-VLAN branch of the function has no br_vlan_is_brentry() test and flips the flag under br->multicast_lock, so it is not affected. The reader is the bridge transmit path. For a master VLAN br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with pmctx = NULL, so IGMP sent to the bridge device re-arms the context's timers after br_multicast_ctx_deinit() has already stopped them. BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0 Write of size 8 at addr ffff88810ac39918 by task brmc/601 __mod_timer+0x51a/0xc50 br_multicast_host_join+0x25b/0x390 __br_multicast_add_group+0x468/0x530 br_ip4_multicast_add_group+0x1a0/0x260 br_multicast_rcv+0x2cda/0x61e0 br_dev_xmit+0x6c4/0x1540 Allocated by task 610: br_vlan_add+0x111/0xb40 br_vlan_info+0x370/0x3e0 Freed by task 0: kfree+0x1a7/0x4f0 rcu_core+0x7dc/0x10a0 Only test br_vlan_is_brentry() when enabling, like the br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before br_multicast_ctx_deinit() drains the context.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80843", "url": "https://ubuntu.com/security/CVE-2026-80843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as \"no auth algorithm attached yet\" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80844", "url": "https://ubuntu.com/security/CVE-2026-80844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80846", "url": "https://ubuntu.com/security/CVE-2026-80846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80848", "url": "https://ubuntu.com/security/CVE-2026-80848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80852", "url": "https://ubuntu.com/security/CVE-2026-80852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: device: fix out-of-bounds write in tls_append_frag() Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: worker_thread (kernel/workqueue.c:3405 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": "high", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80854", "url": "https://ubuntu.com/security/CVE-2026-80854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: keep port count until LUN teardown completes tcm_usbg_drop_nexus() permits session removal once tpg_port_count reaches zero. However, usbg_port_unlink() currently decrements that count from the fabric_pre_unlink() callback, before core_dev_del_lun() waits for active se_lun references to drain. If removal of the last LUN races a nexus removal, the latter can observe a zero port count and call target_remove_session(). This frees sess_cmd_map while an in-flight struct usbg_cmd, including its work item, can still be accessed. Overlapping the last-LUN unlink with nexus removal reproduces this lifetime violation as a DEBUG_OBJECTS \"free active\" warning for usbg_cmd_work, followed by a target-core BUG/Oops. The generic target-core unlink path has no callback after core_dev_del_lun() completes. Add an optional fabric_post_unlink() callback and use it for the f_tcm port count. The count now remains nonzero until core_dev_del_lun() has finished draining active LUN references, preventing nexus removal from freeing the session during command completion.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80855", "url": "https://ubuntu.com/security/CVE-2026-80855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open(\"file\", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80856", "url": "https://ubuntu.com/security/CVE-2026-80856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80923", "url": "https://ubuntu.com/security/CVE-2026-80923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80762", "url": "https://ubuntu.com/security/CVE-2026-80762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix accept list UAF during suspend hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait. The following interleaving causes the use-after-free: hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next KASAN reported: BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10 Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0 Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80780", "url": "https://ubuntu.com/security/CVE-2026-80780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: pidff: fix OOB write when hid->inputs is empty hid_pidff_init_with_quirks() derives its input_dev from \tlist_entry(hid->inputs.next, struct hid_input, list) without first checking that hid->inputs is non-empty. The list member of struct hid_input is at offset 0, so on an empty list list_entry() yields &hid->inputs itself and the following hidinput->input load reads an unrelated member of struct hid_device. dev is then a type-confused pointer, and force-feedback init writes through it: each set_bit(FF_*, dev->ffbit) stores 8 bytes at dev + 192, past the end of the object dev actually aliases, and input_ff_create() adds further writes of a heap pointer and two function pointers. Until hid-universal-pidff the only caller was hid_pidff_init() from usbhid, which runs under HID_CLAIMED_INPUT and therefore always has at least one hid_input. universal_pidff_probe() starts the device with HID_CONNECT_DEFAULT & ~HID_CONNECT_FF and then calls hid_pidff_init_with_quirks() directly whenever the descriptor carries a PID usage page, bypassing that gate. A report descriptor whose only application collection is on HID_UP_PID leaves hid->inputs empty while hid_connect() still succeeds through the hidraw claim, so probe reaches the unguarded list_entry(). The write happens in the USB probe path, on the hotplug workqueue, so plugging in a malicious device is enough to trigger it; no attacker software and no logged-in user are required. KASAN reports an 8-byte out-of-bounds write in hid_pidff_init_with_quirks() reached from universal_pidff_probe(). Check for an empty list before deriving dev and return -ENODEV, as the other HID force-feedback drivers already do. universal_pidff_probe() propagates the error and unwinds. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80766", "url": "https://ubuntu.com/security/CVE-2026-80766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: uclogic: fix use-after-free of inrange_timer on remove uclogic_remove() cancels the pen in-range timer and then stops the device: \ttimer_delete_sync(&drvdata->inrange_timer); \thid_hw_stop(hdev); timer_delete_sync() only guarantees the timer is idle at that instant. uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop() stops the transport several lines later, and every report with pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer: \tmod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); A report landing between the timer_delete_sync() call and the transport teardown in hid_hw_stop() re-arms inrange_timer after it was cancelled. uclogic_remove() then returns and the devm drvdata is freed, while hid_hw_stop() has already freed the input device drvdata->pen_input points at, so when the timer fires ~100 ms later uclogic_inrange_timeout() dereferences freed memory -- a use-after-free in timer-softirq context. Swapping the two calls is not a fix: stopping the device first frees drvdata->pen_input via hidinput_disconnect() while the timer may still be pending, so a timer already armed before removal fires on the freed input device in the window before timer_delete_sync() runs. Use timer_shutdown_sync() before hid_hw_stop() instead. It cancels the timer, waits for a running callback while pen_input is still valid, and prevents any further re-arming -- a later mod_timer() from an in-flight report is silently ignored -- so the timer is provably dead before hid_hw_stop() frees the inputs. This is the ordering the timer core documents for this \"timer re-armed from another path\" teardown case.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80768", "url": "https://ubuntu.com/security/CVE-2026-80768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: ft260: fix stack-use-after-return write in I2C read race ft260_i2c_read() points dev->read_buf at a caller-supplied buffer (often an on-stack variable), arms a completion and waits up to five seconds for the device to return the data. The HID input callback ft260_raw_event() runs in the input/IRQ path, independent of the dev->lock mutex held by the read path, and copies the device-supplied payload into dev->read_buf after a plain NULL check. These two paths share read_buf, read_idx and read_len with no serialization. If the device delays its response until the read times out, ft260_i2c_read() resets the controller, clears read_buf and returns, unwinding the stack frame the buffer lived in. A response that arrives at that moment lets ft260_raw_event() pass the NULL check and then memcpy() the device-controlled payload into the now-freed stack location, a bounded but attacker-influenced stack-use-after-return write triggerable by malicious or malfunctioning hardware. Add a dedicated spinlock that serializes every access to read_buf, read_idx and read_len. ft260_raw_event() now holds it across the NULL check, the memcpy and the index update, while the read path takes it when arming and when clearing the buffer, so the teardown can no longer slip between the check and the copy.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80770", "url": "https://ubuntu.com/security/CVE-2026-80770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: stop device IO before hid_hw_stop on probe failure nintendo_hid_probe() calls hid_device_io_start() before joycon_init() and joycon_leds_create(). If either fails, the error path jumps to err_close which calls hid_hw_close()/hid_hw_stop() without first calling hid_device_io_stop(). hid_hw_stop() does not stop device IO, so hid_input_report() may still run and access driver data that is being torn down, resulting in a use-after-free. Add an err_io_stop label that calls hid_device_io_stop() before hid_hw_close(), and point the two post-io_start error paths at it.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80789", "url": "https://ubuntu.com/security/CVE-2026-80789", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: \tcmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80783", "url": "https://ubuntu.com/security/CVE-2026-80783", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack two touch reports into one, by splitting the packet and calling itself on each half. The only guard against runaway recursion is a \"size < 1\" check, which stops zero-sized calls but does not bound the recursion depth. A malicious HID device that matches this driver can send a report starting with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level consumes two bytes and recurses on the remainder, so an incoming report of up to HID_MAX_BUFFER_SIZE (16 KiB) drives roughly 8000 nested calls. That easily exhausts the 16 KiB kernel stack, leading to a stack overflow: a panic with CONFIG_VMAP_STACK, or memory corruption without it. A double report only ever wraps two normal reports; it is never legitimately nested. Refuse to re-enter the DOUBLE_REPORT_ID case from a recursive call so the recursion depth is bounded to two, while all valid packets keep being parsed exactly as before.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80796", "url": "https://ubuntu.com/security/CVE-2026-80796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add data_len bound checks to activation parameter extractors nci_extract_activation_params_iso_dep() and nci_extract_activation_params_nfc_dep() read an inner length byte from the NCI RF_INTF_ACTIVATED_NTF payload and use it to memcpy() into fixed kernel buffers, but neither function receives the caller-validated activation_params_len. A crafted NCI notification with activation_params_len=1 and an inner length byte of up to 20 (NFC-A) or 50 (NFC-B) causes memcpy() to read that many bytes past the one valid byte in the activation params region -- a slab out-of-bounds read of kernel memory adjacent to the NCI skb. The sibling nci_extract_rf_params_*() family was given equivalent protection by commit 571dcbeb8e63 (\"net: nfc: nci: Fix parameter validation for packet data\"), but the two activation parameter extractors were not updated at that time. Add a data_len parameter to both functions, guard against an empty region before consuming the inner length byte, decrement the remaining count after consuming it, and clamp the copy length to what is actually available. Update both call sites to pass ntf.activation_params_len, which is already validated against the skb at ntf.c:801.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80807", "url": "https://ubuntu.com/security/CVE-2026-80807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-64070", "url": "https://ubuntu.com/security/CVE-2026-64070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/hv-gpci: fix preempt count leak in sysfs show paths Four sysfs show() callbacks in hv-gpci take get_cpu_var(hv_gpci_reqb) (which calls preempt_disable()) but only call the matching put_cpu_var() on the error path under the 'out:' label. Every successful read leaks one preempt_disable(): processor_bus_topology_show() processor_config_show() affinity_domain_via_virtual_processor_show() affinity_domain_via_domain_show() (affinity_domain_via_partition_show() was already correct.) On a CONFIG_PREEMPT=y kernel, repeated reads raise preempt_count and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandler_disabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in call_usermodehelper_exec -> wait_for_completion_state -> schedule: BUG: scheduling while atomic: //0x00000004 ... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 Add an out_success label that calls put_cpu_var() before returning the byte count, mirroring affinity_domain_via_partition_show().", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64082", "url": "https://ubuntu.com/security/CVE-2026-64082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Fix register corruption from uninitialized cregs on error compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's pt_regs, corrupting its register state and potentially leaking kernel stack contents. compat_restore_sigcontext() has the same issue: it calls cregs_to_regs() even when __copy_from_user() fails, leading to the same corruption of the signal-returning task's register state on error. Only call cregs_to_regs() when the user copy succeeds.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53089", "url": "https://ubuntu.com/security/CVE-2026-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-45963", "url": "https://ubuntu.com/security/CVE-2026-45963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: nau8821: Cancel delayed work on component remove Attempting to unload the driver while a jack detection work is pending would likely crash the kernel when it is eventually scheduled for execution: [ 1984.896308] BUG: unable to handle page fault for address: ffffffffc10c2a20 [...] [ 1984.896388] Hardware name: Valve Jupiter/Jupiter, BIOS F7A0131 01/30/2024 [ 1984.896396] Workqueue: events nau8821_jdet_work [snd_soc_nau8821] [ 1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0 [...] [ 1984.896504] Call Trace: [ 1984.896511] [ 1984.896524] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896572] ? snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core] [ 1984.896622] nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [ 1984.896636] process_one_work+0x211/0x590 [ 1984.896649] ? srso_return_thunk+0x5/0x5f [ 1984.896670] worker_thread+0x1cd/0x3a0 Cancel unscheduled jdet_work or wait for its execution to finish before the component driver gets removed.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-40168", "url": "https://ubuntu.com/security/CVE-2025-40168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller.", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40139", "url": "https://ubuntu.com/security/CVE-2025-40139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set(). smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname(). Note that the returned value of smc_clc_prfx_set() is not used in the caller. While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.", "cve_priority": "high", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40102", "url": "https://ubuntu.com/security/CVE-2025-40102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40064", "url": "https://ubuntu.com/security/CVE-2025-40064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smc: Fix use-after-free in __pnet_find_base_ndev(). syzbot reported use-after-free of net_device in __pnet_find_base_ndev(), which was called during connect(). [0] smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passes down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened at __pnet_find_base_ndev() when the dev is first used. This means dev had already been freed before acquiring RTNL in pnet_find_base_ndev(). While dev is going away, dst->dev could be swapped with blackhole_netdev, and the dev's refcnt by dst will be released. We must hold dev's refcnt before calling smc_pnet_find_ism_resource(). Also, smc_pnet_find_roce_resource() has the same problem. Let's use __sk_dst_get() and dst_dev_rcu() in the two functions. [0]: BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609 CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: dump_stack_lvl+0x189/0x250 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 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff 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 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node ---truncated---", "cve_priority": "high", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-39925", "url": "https://ubuntu.com/security/CVE-2025-39925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: implement NETDEV_UNREGISTER notification handler syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 (\"can: j1939: move j1939_priv_put() into sk_destruct callback\") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on \"struct j1939_priv\" held by j1939_sk_bind() call prevents \"struct net_device\" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. [mkl: remove space in front of label]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39833", "url": "https://ubuntu.com/security/CVE-2025-39833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix warning when deleting uninitialized timer With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat: [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10 [ 250.242058] ? __timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update.", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-38237", "url": "https://ubuntu.com/security/CVE-2025-38237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode() In fimc_is_hw_change_mode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready. Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling.", "cve_priority": "medium", "cve_public_date": "2025-07-08 08:15:00 UTC" }, { "cve": "CVE-2025-38206", "url": "https://ubuntu.com/security/CVE-2025-38206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix double free in delayed_free The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it.", "cve_priority": "low", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38203", "url": "https://ubuntu.com/security/CVE-2025-38203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix null-ptr-deref in jfs_ioc_trim [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program.", "cve_priority": "low", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-22104", "url": "https://ubuntu.com/security/CVE-2025-22104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e", "cve_priority": "low", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2024-58095", "url": "https://ubuntu.com/security/CVE-2024-58095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2024-58094", "url": "https://ubuntu.com/security/CVE-2024-58094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for \"read-only\" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `xtTruncate` function will be called with the \"COMMIT_WMAP\" flag, preventing modifications in \"read-only\" mode.", "cve_priority": "low", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2026-80806", "url": "https://ubuntu.com/security/CVE-2026-80806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable DAX on new encrypted files Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with \"-o dax=always\". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 (\"fs/ext4: Only change S_DAX on inode load\"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when \"-o dax=always\" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80863", "url": "https://ubuntu.com/security/CVE-2026-80863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix OOB in free_rd_atomic_resources() free_rd_atomic_resources() iterates using qp->attr.max_dest_rd_atomic. Updating max_dest_rd_atomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063 CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 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 lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xf7/0x600 mm/kasan/report.c:482 kasan_report+0xe4/0x120 mm/kasan/report.c:595 free_rd_atomic_resource drivers/infiniband/sw/rxe/rxe_qp.c:180 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:171 [inline] free_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:163 [inline] rxe_qp_from_attr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:712 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_main.c:680 vfs_write+0x2aa/0x1070 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:740 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 Allocated by task 11063: kasan_save_stack+0x33/0x60 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5296 [inline] __kmalloc_noprof+0x32a/0x850 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 [inline] kzalloc_noprof include/linux/slab.h:1188 [inline] alloc_rd_atomic_resources drivers/infiniband/sw/rxe/rxe_qp.c:155 [inline] rxe_qp_from_attr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxe_qp.c:714 rxe_modify_qp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxe_verbs.c:623 ib_security_modify_qp+0x223/0xfa0 drivers/infiniband/core/security.c:625 _ib_modify_qp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modify_qp+0x13ca/0x1940 drivers/infiniband/core/uverbs_cmd.c:1932 ib_uverbs_modify_qp+0xcb/0x120 drivers/infiniband/core/uverbs_cmd.c:1958 ib_uverbs_write+0xb86/0x1030 drivers/infiniband/core/uverbs_ma ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80590", "url": "https://ubuntu.com/security/CVE-2026-80590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 (\"net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list\") and by commit 9e4b7a99a03a (\"net: gso: fix panic on frag_list with mixed head alloc types\") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 (\"tun: Allow GSO using virtio_net_hdr\"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80763", "url": "https://ubuntu.com/security/CVE-2026-80763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate LE Set CIG Parameters response The Command Complete dispatch validates only the fixed part of the LE Set CIG Parameters response. After that part is pulled from the skb, hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the trailing handle array. Matching num_handles against the command's num_cis does not guarantee that the response contains the advertised handles. A truncated response from a malfunctioning controller can therefore make the handler read beyond the skb data. Validate that the remaining skb data contains all advertised handles. Include this in the existing response validation so malformed responses also follow the established CIG failure handling.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80764", "url": "https://ubuntu.com/security/CVE-2026-80764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix LE list UAF on reset hci_cc_reset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them. This permits the reset completion and a debugfs read to interleave as follows: hci_rx_work debugfs reader ----------- -------------- lock hdev->lock fetch current entry list_del(entry) kfree(entry) read entry fields The reader then dereferences a freed list entry and may follow its stale next pointer. KASAN reported: BUG: KASAN: slab-use-after-free in white_list_show+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95 Call Trace: white_list_show+0x15f/0x180 seq_read_iter+0x3ff/0x1190 seq_read+0x267/0x3d0 vfs_read+0x177/0xa20 ksys_read+0xf7/0x1c0 Allocated by task 91: hci_bdaddr_list_add+0x1a6/0x3a0 hci_cc_le_add_to_accept_list+0xab/0x140 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Freed by task 90: kfree+0x131/0x3c0 hci_bdaddr_list_clear+0xd8/0x160 hci_cc_reset+0x28a/0x370 hci_cmd_complete_evt+0x26c/0x9a0 hci_event_packet+0x454/0xb20 hci_rx_work+0x293/0x730 Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention.", "cve_priority": "low", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80765", "url": "https://ubuntu.com/security/CVE-2026-80765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: validate initial device info bounds The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO messages that contain a HID descriptor followed by the report descriptor bytes. mousevsc_on_receive_device_info() trusts bLength and wDescriptorLength without checking that the received packet contains both byte ranges. A malformed host or backend message can therefore make the guest read past the received VMBus packet while copying the report descriptor. Pass the received initial-device-info size into the parser and reject descriptor lengths that exceed the packet. Impact: A malicious Hyper-V host or backend can crash a guest by sending a short initial device-info message with an oversized HID report descriptor length.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80767", "url": "https://ubuntu.com/security/CVE-2026-80767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: sensor: custom: Fix use-after-free in enable_sensor enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80918", "url": "https://ubuntu.com/security/CVE-2026-80918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80772", "url": "https://ubuntu.com/security/CVE-2026-80772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler() joycon_ctlr_read_handler() casts an incoming HID input report to struct joycon_input_report and parses it, guarding the cast only with a 12-byte length check: \tif (size >= 12) /* make sure it contains the input report */ \t\tjoycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report is 49 bytes: a 13-byte header followed by a union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report() -> joycon_parse_imu_report() walks that union (struct offsets 13..48), so a report of exactly 12 bytes with data[0] == JC_INPUT_IMU_DATA passes the guard yet is read up to 37 bytes past its declared length. The over-read bytes are decoded into accelerometer/gyroscope values and forwarded to userspace through the \"(IMU)\" input device, leaking driver-internal memory. data[0] and size are fully controlled by a malicious or spoofed Joy-Con/Pro Controller. Receive buffers are sized to the maximum report length, so this is an over-read within the allocation rather than a slab OOB, but the decoded bytes still reach userspace. The sibling subcmd path in joycon_ctlr_handle_event() already bounds the same cast correctly: \tif (size < sizeof(struct joycon_input_report) || \t data[0] != JC_INPUT_SUBCMD_REPLY) \t\tbreak; Use the same sizeof(struct joycon_input_report) bound here.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80784", "url": "https://ubuntu.com/security/CVE-2026-80784", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix memory leak from alloc-during-teardown race mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket teardown, dropping the lock between the two. A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcp_token_get_sock() and, in mptcp_pm_nl_announce_doit(), calls mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which invokes mptcp_destroy_common() without dropping the sock refcount, before the handler completes. If the lock acquisitions interleave such that mptcp_pm_destroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and mptcp_pm_addr_entry objects (from mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent ANNOUNCE + close load against the userspace PM. Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcp_pm_destroy() frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the later alloc observes the bit and refuses. Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-74509", "url": "https://ubuntu.com/security/CVE-2026-74509", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix advertising data UAFs hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response. An advertising termination event can therefore interleave as follows: hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false KASAN reported: BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller. Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64581", "url": "https://ubuntu.com/security/CVE-2026-64581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-80781", "url": "https://ubuntu.com/security/CVE-2026-80781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field->usage in hid_set_field() hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset: \thid_dump_input(field->report->device, field->usage + offset, value); \tif (offset >= field->report_count) { \t\thid_err(...); \t\treturn -1; \t} Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array. A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs \"offset (1) exceeds report_count (1)\" from the guard that runs only afterwards. Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80782", "url": "https://ubuntu.com/security/CVE-2026-80782", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: do not keep a stale msc->input if no input is claimed magicmouse_input_mapping() caches the first hid_input's input_dev in msc->input while the report descriptor is parsed, and the rest of the driver treats a non-NULL msc->input as proof that an input device was registered. That does not hold on the hid-input error path. If hidinput_connect() fails -- for instance because input_register_device() returns an error -- it unwinds through hidinput_disconnect(), which frees every input_dev it created, including the one cached in msc->input. The failure does not abort the probe. hid_connect() only skips the claim: \tif ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev, \t\t\t\tconnect_mask & HID_CONNECT_HIDINPUT_FORCE)) \t\thdev->claimed |= HID_CLAIMED_INPUT; and the \"device has no listeners\" bailout below it does not fire for this driver, which sets ->raw_event; on the USB Magic Mouse 2 / Magic Trackpad 2 paths hidraw and hiddev are claimed as well. hid_hw_start() therefore returns 0 and magicmouse_probe() continues with msc->input pointing at freed memory. Being non-NULL, it passes the \"input not registered\" check in probe and the NULL checks in ->raw_event and ->event, so the next input report dereferences freed memory. Clear msc->input when the HID core did not claim an input device, so the existing NULL checks cover this case as well.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80583", "url": "https://ubuntu.com/security/CVE-2026-80583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses The \"DEC0 MODE\" to \"DEC7 MODE\" controls are enumerated, but tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but tx-macro was missed. On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value sanity check catches the 4 bytes written past the enumerated item and every read of these controls fails with -EINVAL: snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80581", "url": "https://ubuntu.com/security/CVE-2026-80581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80788", "url": "https://ubuntu.com/security/CVE-2026-80788", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator. A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message: WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80790", "url": "https://ubuntu.com/security/CVE-2026-80790", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: fix invalid free in LS IOD error path nvmet_fc_alloc_ls_iodlist() advances iod while initializing the LS IOD array. If an rqstbuf allocation or response buffer DMA mapping fails, the unwind loop decrements iod past the start of the array. The final kfree(iod) therefore frees an address before the allocated object. This can be reproduced with nvme-fcloop and failslab by setting fail-nth to 6 before creating a target port. KASAN reports: BUG: KASAN: invalid-free in nvmet_fc_register_targetport Free of addr ffff88816cf8ff48 by task nvmet_fail_nth/9552 Free the original allocation base stored in tgtport->iod instead. With this fix applied, the same sysfs write with fail-nth=6 returns -ENOMEM without any KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80791", "url": "https://ubuntu.com/security/CVE-2026-80791", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: zero the AUTH_RECEIVE response buffer nvmet_execute_auth_receive() allocates the response buffer with kmalloc() sized by the host-supplied AUTH_RECEIVE allocation length, but the DH-HMAC-CHAP builders write only a fixed-size message into it. The full allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a remote initiator receives the bytes past the built message -- up to nearly a page of uninitialized slab -- during the pre-authentication handshake. Allocate the buffer with kzalloc() so the unwritten tail is zeroed before it is sent; conforming responses are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80792", "url": "https://ubuntu.com/security/CVE-2026-80792", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix use-after-free in ip6_finish_output2() ip6_finish_output2() caches a pointer to the IPv6 destination address (daddr) before invoking lwtunnel_xmit(). The LWT-BPF transmit path or other encapsulation operations within lwtunnel_xmit() can reallocate the skb head, freeing the memory that daddr points to. When lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, the function continues to use the stale daddr pointer to compute the nexthop and to look up or create the neighbour entry. This results in a use-after-free read, which can leak sensitive kernel data, pollute the neighbour table with arbitrary values, misdirect traffic, or crash the system. Fix this by re-fetching the IPv6 header and the destination address pointer after lwtunnel_xmit() returns LWTUNNEL_XMIT_CONTINUE, ensuring that the subsequent nexthop computation and neighbour lookup operate on valid memory.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80793", "url": "https://ubuntu.com/security/CVE-2026-80793", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: reject undersized MTUs in ip_do_fragment() ip_do_fragment() subtracts the IPv4 header length from the effective MTU and passes the resulting payload MTU to ip_frag_next(). If the effective MTU is smaller than hlen + 8, ip_frag_next() rounds the fragment payload length down to zero. The fragmentation state then never makes forward progress: state->left, state->ptr and state->offset stay unchanged while ip_do_fragment() keeps allocating and transmitting header-only fragments until the softlockup detector fires. This is reproducible with a route installed using \"mtu lock 20\", but it is also reproducible without route MTU lock, for example by forwarding a packet to a device whose MTU is 20. Fix it in ip_do_fragment() by rejecting mtu < hlen + 8 with -EMSGSIZE, matching the existing IPv6 fragmentation check.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80557", "url": "https://ubuntu.com/security/CVE-2026-80557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix OOB read in decode_watchers() via missing bounds check ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80572", "url": "https://ubuntu.com/security/CVE-2026-80572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: byd - synchronize timer deletion before freeing private data byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op.", "cve_priority": "low", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80794", "url": "https://ubuntu.com/security/CVE-2026-80794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix uninit-value in the RF discover/activated NTF handlers nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each parse a notification into an on-stack struct (nci_rf_discover_ntf / nci_rf_intf_activated_ntf) that is not initialised. The RF technology-specific parameters are only extracted when rf_tech_specific_params_len is non-zero, so a notification that reports a zero length leaves the rf_tech_specific_params union uninitialised - and both handlers then pass it to nci_add_new_protocol(), which reads it: - discover: nci_add_new_target() -> nci_add_new_protocol(); - activated: nci_target_auto_activated() -> nci_add_new_protocol(). nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch condition and a memcpy() length and copies nfcid1/sens_res/sel_res into ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET. BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0 nci_add_new_protocol+0x624/0x6c0 nci_ntf_packet+0x25b2/0x3c30 nci_rx_work+0x318/0x5d0 process_scheduled_works+0x84b/0x17a0 worker_thread+0xc10/0x11b0 kthread+0x376/0x500 Local variable ntf.i created at: nci_ntf_packet+0xbc2/0x3c30 Zero-initialise both on-stack notifications so the union reads back as zero when no technology-specific parameters are present.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80795", "url": "https://ubuntu.com/security/CVE-2026-80795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix out-of-bounds write in nci_target_auto_activated() nci_target_auto_activated() appends a target to the fixed-size array ndev->targets[NCI_MAX_DISCOVERED_TARGETS] and increments ndev->n_targets without first checking the array is full; unlike its sibling nci_add_new_target(), which bails out when n_targets already equals NCI_MAX_DISCOVERED_TARGETS. ndev->n_targets is only cleared by nci_clear_target_list(), so an NFCC that repeatedly re-runs discovery (RF_DISCOVER_RSP, which re-enters NCI_DISCOVERY without clearing the target list) and reports an auto-activated target (RF_INTF_ACTIVATED_NTF) drives n_targets past the limit. The append then writes a struct nfc_target past the end of the array (a slab out-of-bounds write), and nfc_targets_found() goes on to walk the array with the inflated count: BUG: KASAN: slab-out-of-bounds in nci_add_new_protocol+0x94/0x2ac [nci] Write of size 2 at addr ffff0000c7299a18 by task kworker/u8:0/12 Workqueue: nfc0_nci_rx_wq nci_rx_work [nci] Call trace: nci_add_new_protocol+0x94/0x2ac [nci] nci_ntf_packet+0xddc/0x11a0 [nci] nci_rx_work+0x15c/0x1e0 [nci] process_one_work+0x2dc/0x500 worker_thread+0x240/0x460 kthread+0x1c0/0x1d0 ret_from_fork+0x10/0x20 The buggy address belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1024 bytes to the right of allocated 1560-byte region [ffff0000c7299000, ffff0000c7299618) Guard nci_target_auto_activated() with the same check used by nci_add_new_target().", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80823", "url": "https://ubuntu.com/security/CVE-2026-80823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: \tgb_len = atr_req->length - sizeof(struct st21nfca_atr_req); \t... \tmemcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80797", "url": "https://ubuntu.com/security/CVE-2026-80797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: purge fragmented skbs during cleanup pn53x_common_clean() purges resp_q before freeing the common PN533 state, but it leaves fragment_skb untouched. The fragmentation helpers queue transmit fragments there while sending large initiator or target-mode frames, and those skbs remain owned by the driver until they are sent or discarded. If the device is removed while fragments are still queued, the common cleanup path frees the PN533 state without releasing the queued fragment skbs, leaking them. Purge fragment_skb during cleanup alongside resp_q.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80798", "url": "https://ubuntu.com/security/CVE-2026-80798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes \ttlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80799", "url": "https://ubuntu.com/security/CVE-2026-80799", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80800", "url": "https://ubuntu.com/security/CVE-2026-80800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e (\"nfc: llcp: bound SNL TLV parsing to the skb and add length checks\") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 (\"nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers\") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as \"skb->len - LLCP_HEADER_SIZE\" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80801", "url": "https://ubuntu.com/security/CVE-2026-80801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: microread: validate target discovery payload lengths microread_target_discovered() parses target discovery payloads from skb->data according to the HCI gate. The fixed field offsets and UID copies were checked only against the destination nfc_target buffers, not against the actual skb length. Validate that each gate-specific payload contains the fixed fields and UID bytes before reading or copying them.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80802", "url": "https://ubuntu.com/security/CVE-2026-80802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: bound the device-reported read length and fix an skb leak fdp_nci_i2c_read() takes the next packet length from two device-supplied bytes and never validates it. The value is a u16 used as the i2c_master_recv() count into a 261-byte on-stack buffer: a malicious, counterfeit or malfunctioning controller (or an i2c bus interposer) can drive it far past the buffer for a stack out-of-bounds write that clobbers the canary and return address, or below the minimum frame size (directly, or by truncating the computed sum) so the header/LRC strip and the next length read run past a short receive. Reject a length outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a corrupted packet already is, and force resynchronization. The same loop allocates one data skb per iteration and assumes a length packet followed by a data packet; a device that sends two data packets in one call leaks the first skb when the second allocation overwrites it. Free a previously allocated skb before allocating the next.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80803", "url": "https://ubuntu.com/security/CVE-2026-80803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: digital: clamp SENSF_RES length to the destination buffer digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res field without an upper-bound check. A nearby malicious NFC-F device can send an oversized SENSF_RES response to overflow the stack-local struct nfc_target. Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80547", "url": "https://ubuntu.com/security/CVE-2026-80547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Implement a crw lock Unlike the channel_program struct, which covers synchronous I/O submissions and asynchronous interrupts, the CRW region relies exclusively on asynchronous events coming from hardware. Implement a lock to manage the list of those payloads, to ensure they are read cohesively.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80551", "url": "https://ubuntu.com/security/CVE-2026-80551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure first IDAW remains constant The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80555", "url": "https://ubuntu.com/security/CVE-2026-80555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Free all memory if cp_init() fails The routine cp_free() is called to unpin/free any memory once an I/O is completed successfully, or if cp_prefetch() fails. But if cp_init() fails, and cp->initialized is not enabled, the same routine cannot be used to free all the memory. An attempt to address this exists in ccwchain_handle_ccw(), where a single call to ccwchain_free() is made for the currently-processed CCW segment. But this will leak other segments (created as a result of a Transfer in Channel) that had been allocated as part of the same channel program. Address this by performing the cleanup outside of the recursive ccwchain_handle_ccw()/ccwchain_loop_tic() logic.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80562", "url": "https://ubuntu.com/security/CVE-2026-80562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_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. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. 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, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 (\"gpio: pch: use raw_spinlock_t for the register lock\"); this driver shares the same structure as gpio-pch.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80805", "url": "https://ubuntu.com/security/CVE-2026-80805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80808", "url": "https://ubuntu.com/security/CVE-2026-80808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80916", "url": "https://ubuntu.com/security/CVE-2026-80916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems.", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-80809", "url": "https://ubuntu.com/security/CVE-2026-80809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80812", "url": "https://ubuntu.com/security/CVE-2026-80812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dummy: Check card index validity at probe snd_dummy_probe() blindly trusts that the given devptr->id value is within the proper card index range. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as \"none\", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80536", "url": "https://ubuntu.com/security/CVE-2026-80536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: bounds-check buffer log item's dirty bitmap xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: \tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), \t\titem->ri_buf[i].iov_base, \t\tnbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74662", "url": "https://ubuntu.com/security/CVE-2026-74662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74655", "url": "https://ubuntu.com/security/CVE-2026-74655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: fix TX DMA buffer flush When transmit flushing a qcom-geni UART during an ongoing TX DMA, the UART gets stuck infinitely repeating corrupted TX DMA frames. The DMA-mode uart_ops does not provide a flush_buffer callback, so an in-flight transfer can complete after serial core has reset the transmit kfifo, underflowing its length and resubmitting page-sized transfers indefinitely. Add one that stops the transfer and clears tx_remaining and tx_queued. The stop path was also broken: it unmapped the buffer while the serial engine could still read it, and never reset the TX DMA state machine. Cancel the main sequencer command first, then reset the state machine and wait for it before unmapping. Drop the early return so a pending mapping is also cleaned up when the main command is inactive. The bug can be triggered from userspace with a large write immediately followed by TCOFLUSH. A following tcdrain will hang forever. The bug was reproduced and this fix was validated on Arduino Uno Q (QRB2210) using /dev/ttyHS1.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74637", "url": "https://ubuntu.com/security/CVE-2026-74637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80737", "url": "https://ubuntu.com/security/CVE-2026-80737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: synchronize DMA teardown dmaengine_terminate_all() does not wait for a running callback, so the TX callback can still touch the TX buffer after it is freed. The RX poll timer reads the RX buffers without the port lock. Switch to dmaengine_terminate_sync() and delete the RX timer before freeing the buffers.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74626", "url": "https://ubuntu.com/security/CVE-2026-74626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80814", "url": "https://ubuntu.com/security/CVE-2026-80814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rndis_host: add overflow check in rndis_rx_fixup() Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80819", "url": "https://ubuntu.com/security/CVE-2026-80819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: \tif (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { \t\trfcomm_dlc_accept(d); \t\treturn 0; \t} and rfcomm_dlc_accept() dereferences the session on its first line: \tstruct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as \"called under rfcomm_lock()\". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: \td->state = BT_CLOSED; \t__rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.", "cve_priority": "medium", "cve_public_date": "2026-09-04 16:18:00 UTC" }, { "cve": "CVE-2026-80917", "url": "https://ubuntu.com/security/CVE-2026-80917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using \"pci-host-cam-generic\" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [] pci_generic_config_read+0x40/0xb0 [] pci_bus_read_config_dword+0x50/0xb0 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [] pci_scan_single_device+0xa4/0x11c [] pci_scan_slot+0x9c/0x23c [] pci_scan_child_bus_extend+0x58/0x2f4 [] pci_scan_root_bus_bridge+0x64/0xe8 [] pci_host_probe+0x20/0xc8 [] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]", "cve_priority": "medium", "cve_public_date": "2026-09-09 17:17:00 UTC" }, { "cve": "CVE-2026-74601", "url": "https://ubuntu.com/security/CVE-2026-74601", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Use current_context for safe per-CPU buffer swap The ring_buffer_swap_cpu() function currently checks the per-CPU committing counter to determine if a buffer is actively being written to before performing the swap. However, there exists a race window where this check can be bypassed: ring_buffer_lock_reserve cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a rb_reserve_next_event rb_start_commit // inc committing if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...} __rb_reserve_next rb_move_tail rb_end_commit(cpu_buffer); // dec committing => 0 /* interrupt hits here, successfully swaps! */ local_inc(&cpu_buffer->committing); ring_buffer_unlock_commit cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b rb_commit rb_end_commit RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing)) // triggers warning The committing counter can temporarily drop to 0 during a single write operation (within rb_move_tail), creating a window where swap can succeed even though the write is still in progress. This leads to inconsistent buffer state and triggers the RB_WARN_ON in rb_commit(). Replace the committing counter check with current_context checks, which are set at the entry of ring_buffer_lock_reserve() and remain valid throughout the entire write operation, providing a reliable indicator of buffer busy state during swap.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74628", "url": "https://ubuntu.com/security/CVE-2026-74628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free of the socket by its timers The x25 timers are armed with mod_timer() and cancelled with timer_delete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU. x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall sk->sk_timer after __x25_destroy_socket() has passed its cancel point. The following __sock_put() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close(). timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and x25_timer_expiry() both reach the cancels from inside the timer they would wait on, through __x25_destroy_socket() and x25_disconnect(). Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while sk_hashed(sk) is still true, since __x25_destroy_socket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25_destroy_timer(). Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74736", "url": "https://ubuntu.com/security/CVE-2026-74736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74737", "url": "https://ubuntu.com/security/CVE-2026-74737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74739", "url": "https://ubuntu.com/security/CVE-2026-74739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74740", "url": "https://ubuntu.com/security/CVE-2026-74740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL. Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80742", "url": "https://ubuntu.com/security/CVE-2026-80742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_packet: Don't send zero-byte data in tpacket_snd(). syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 When sending 0-byte packets via TPACKET ring buffer on devices with no hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() populates an skb with skb->len == 0 and returns 0. tpacket_snd() then forwards this empty skb to packet_xmit(), causing __dev_queue_xmit() to hit skb_assert_len(skb). Similar checks exist in packet_snd() via commit dc633700f00f (\"net/af_packet: check len when min_header_len equals to 0\") and in packet_sendmsg_spkt() via commit 6a341729fb31 (\"af_packet: Don't send zero-byte data in packet_sendmsg_spkt().\"). Return -EINVAL in tpacket_fill_skb() when skb->len is zero to reject zero-length packets in tpacket_snd().", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80743", "url": "https://ubuntu.com/security/CVE-2026-80743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash. Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80904", "url": "https://ubuntu.com/security/CVE-2026-80904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: Fail tls_sw_splice_read() after a failed async decrypt When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80906", "url": "https://ubuntu.com/security/CVE-2026-80906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: packet: fix wrong transport_header when sending VLAN-tagged frame In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to the outer VLAN EtherType (e.g. ETH_P_8021Q), while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-74743", "url": "https://ubuntu.com/security/CVE-2026-74743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74744", "url": "https://ubuntu.com/security/CVE-2026-74744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74746", "url": "https://ubuntu.com/security/CVE-2026-74746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: publish GC-visible tuple last nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-80744", "url": "https://ubuntu.com/security/CVE-2026-80744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug. Trace for example: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nf_tables transaction processing: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Change the condition to WARN_ON_ONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74748", "url": "https://ubuntu.com/security/CVE-2026-74748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix refcount race between list:set GC and swap __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. Resolve the index and decrement under ip_set_ref_lock, as ip_set_swap() already does, keeping the refcount tied to the index rather than to a stale set pointer. kernel BUG at net/netfilter/ipset/ip_set_core.c:685! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ip_set_put_byindex (net/netfilter/ipset/ip_set_core.c:870) Call Trace: list_set_del (net/netfilter/ipset/ip_set_list_set.c:159) set_cleanup_entries (net/netfilter/ipset/ip_set_list_set.c:181) list_set_gc (net/netfilter/ipset/ip_set_list_set.c:578) call_timer_fn (kernel/time/timer.c:1748) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2374) run_timer_softirq (kernel/time/timer.c:2405) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:16:00 UTC" }, { "cve": "CVE-2026-74632", "url": "https://ubuntu.com/security/CVE-2026-74632", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix huge_zero_pfn race Patch series \"mm/huge_memory: fix huge_zero_pfn race\", v2. There is a subtle race in the reference-counted huge_zero_folio implementation. The fast path atomic logic fails to account for the fact that the shrinker (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a racing get_huge_zero_folio() installed a valid value there. This results in huge_zero_folio being correctly set but huge_zero_pfn being set incorrectly and thus is_huge_zero_pfn() and consequently is_huge_zero_pmd() will misidentify the huge zero folio as being an ordinary THP folio. This can result in the huge zero folio being split and otherwise treated incorrectly. The solution to this is very subtle as there is an atomic fast path, and thus ordering in weakly ordered architectures has to be treated very carefully. The first commit fixes the issue by introducing a spinlock around huge_zero_[pfn, folio, refcount] write, with careful consideration paid to load/store ordering in the fast path. It is placed first and kept as small as possible so that it can be backported on its own. The second commit is a pure cleanup which reworks the CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent logic from the dynamically allocated one. This patch (of 2): If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted by huge_zero_refcount and returned by mm_get_huge_zero_folio(). When the caller is done with the huge zero page, its reference count is decremented. Only a shrinker can set the reference count to zero. A race can unfortunately occur between a shrinker decrementing the reference count to zero and a concurrent page fault. This is because shrink_huge_zero_folio_scan() might, if very unlucky, be preempted between setting huge_zero_refcount to zero and writing an invalid value. During this time get_huge_zero_folio() could write to huge_zero_pfn before shrink_huge_zero_folio_scan() resumes. In this event the huge zero folio will be persistently misidentified causing the THP code path to be entered inappropriately for the huge zero folio: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() sets refcount to 0 | xchg() sets huge_zero_folio to NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempted for a long time | Allocate new huge zero folio | | Write valid huge_zero_folio v | Write valid huge_zero_pfn Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite! This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly returning false for a huge zero page which could result in issues like the huge zero folio being incorrectly split. Note that the issue is with huge_zero_pfn not huge_zero_folio, as get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set huge_zero_folio. Fix the issue by introducing a spinlock, huge_zero_lock, to prevent concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount. There needs to be significant care taken here to ensure correctness: The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which is outside of the critical section, and means huge zero allocation is gated on zero huge_zero_refcount. The fast path doesn't use huge_zero_lock, so the critical section is irrelevant to it. So invariants are required - huge_zero_refcount MUST: * Only be set in the huge_zero_lock critical section to ensure serialisation of huge_zero_pfn, huge_zero_folio and ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74607", "url": "https://ubuntu.com/security/CVE-2026-74607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Serialize accesses to the owner and mirror list with separate lock Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues: - in sev_migrate_from(), when the destination KVM is a mirror, the mirror entry is moved from the source's list to the owner's mirror_vms list, without holding the owner's lock unlike other writers of the owner's mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()). A concurrent COPY or destroy can race with sev_migrate_from() and corrupt the list. - In sev_vm_destroy(), the *owner* is still active and could receive concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes sev->enc_context_owner to change. In this case the incorrect VM receives kvm_put_kvm(). The second issue needs particular care because the owner could disappear altogether (even though the race window is impossibly small) between reading it and locking it. There is thus no way to perform the checks under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU (which would allow kvm_get_kvm_safe() under RCU critical section). It is much simpler to just use a global lock, since the critical sections are so small and the new lock is always a leaf lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74599", "url": "https://ubuntu.com/security/CVE-2026-74599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/ptdump: always stabilise against page table freeing using init_mm Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d (\"mm/vmalloc: add interfaces to free unmapped page table\"), so we target this in the Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74672", "url": "https://ubuntu.com/security/CVE-2026-74672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Patch series \"mm: fix UAF caused by race between ptdump and vmap pgtable freeing\", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), which this series has to deal with carefully. This mitigation resolves the issue by acquiring the mmap read lock on init_mm on vmap page table free if a ptdump is in progress. However the fix in this series would cause a deadlock if we were to simply apply it for arm64 without also reverting the change. This is because vmap may acquire the read lock before ptdump attempts to acquire the write lock, which then gets queued, and rwsem starvation rules mean that the (unacknowledged) nested mmap read lock in the arm64 code would also block, meaning the original read lock is never released and thus deadlock. This series works around this by #ifndef CONFIG_ARM64'ing the mmap read lock in vmap logic, then partially reverting commit fa93b45fd397 (\"arm64: Enable vmalloc-huge with ptdump\"), keeping the enablement of huge vmap support, and removing the ifdeffery with the partial revert patch. There are related issues that are also addressed in this series: * x86 page attribute logic, specifically Change Page Attributes (CPA), implements a feature whereby huge ranges can be collapsed into huge leaf entries. This can similarly cause a UAF when done in parallel with a ptdump walk, so similarly acquire the init_mm mmap lock to avoid this. * The CPA logic allows concurrent page table manipulation and CPA collapse, meaning the former risks accessing a page table the latter frees. Fix this by acquiring mmap write lock on init_mm across the whole CPA collapse operation and read lock on the page table manipulation. * x86 and arm64 permit walks of non-kernel mm's (both allowing efi mm walks, and in x86's case arbitrary mm's), so we ensure kernel mappings remain stable by locking the init_mm as well as the mm being walked. The ordering of patches is established for both strict dependencies (the arm64 partial revert in particular has to be done after the vmap changes) and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA fixes are in place). This patch (of 3): Currently there is a nasty ra ---truncated---", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74450", "url": "https://ubuntu.com/security/CVE-2026-74450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix pptable use-after-free amdgpu_dpm_get_pp_table() returns a pointer to a driver-owned power table after dropping adev->pm.mutex. The sysfs path then copies from that pointer. A concurrent pp_table write can replace and free the allocation during the copy, causing a use-after-free. Change the DPM interface to copy into caller-provided storage while the mutex is held. Keep the size-only query for attribute discovery without exposing the driver-owned pointer. (cherry picked from commit f6eed7acfd30099ef7baeb6ba45bb59daad80631)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74474", "url": "https://ubuntu.com/security/CVE-2026-74474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() for transmit path header pulls In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74487", "url": "https://ubuntu.com/security/CVE-2026-74487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access when removing an entry Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 (\"binfmt_misc: restore write access before closing files opened by open_exec()\") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74476", "url": "https://ubuntu.com/security/CVE-2026-74476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: convert frag_list skbs before running XDP A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74479", "url": "https://ubuntu.com/security/CVE-2026-74479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix proc entry use-after-free pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74494", "url": "https://ubuntu.com/security/CVE-2026-74494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject repeated SMB2 NEGOTIATE requests Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80715", "url": "https://ubuntu.com/security/CVE-2026-80715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igc: remove napi_synchronize() in igc_down() When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80526", "url": "https://ubuntu.com/security/CVE-2026-80526", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2562: Validate values for volume writes tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device. Add validation that we are loading a value we have in the array.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80686", "url": "https://ubuntu.com/security/CVE-2026-80686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-68118", "url": "https://ubuntu.com/security/CVE-2026-68118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68431", "url": "https://ubuntu.com/security/CVE-2026-68431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68132", "url": "https://ubuntu.com/security/CVE-2026-68132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: super: fix emergency thaw deadlock on frozen block devices do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68138", "url": "https://ubuntu.com/security/CVE-2026-68138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: serialize qdisc_rtab_list against concurrent get/put qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly linked list qdisc_rtab_list and a plain non-atomic 'int refcnt' with no lock. This was only safe because every caller historically held the RTNL mutex, which serialized all rate-table lookups, inserts and frees. That invariant no longer holds. cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() -> tcf_action_init() -> tcf_action_init_1() -> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate, then race on qdisc_rtab_list and on the non-atomic refcnt, leading to a use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table. qdisc_rtab_list is a single global (not per-netns), so the corrupted object is shared system-wide. BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160 qdisc_put_rtab+0x12f/0x160 tcf_police_init+0xda9/0x1590 tcf_action_init_1+0x460/0x6b0 tcf_action_init+0x439/0xa40 tcf_exts_validate_ex+0x42d/0x550 fl_change+0xddd/0x7da0 tc_new_tfilter+0xaa7/0x2420 rtnetlink_rcv_msg+0x95e/0xe90 which belongs to the cache kmalloc-2k of size 2048 Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before taking the lock; if a concurrent inserter added an identical table in the meantime the freshly allocated one is freed under the lock, so no duplicate is leaked. qdisc_put_rtab() now decrements the refcount and unlinks under the same lock.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68082", "url": "https://ubuntu.com/security/CVE-2026-68082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-08 10:16:00 UTC" }, { "cve": "CVE-2026-68166", "url": "https://ubuntu.com/security/CVE-2026-68166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: prevent registration of special VMAs Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68159", "url": "https://ubuntu.com/security/CVE-2026-68159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE __decode_pg_temp() decodes an user-controlled length but only rejects values large enough to overflow the allocation; it does not bound it to CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack out-of-bounds write. An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer entries at decode time. The bound is well below the old overflow threshold, so it also covers the allocation-size overflow the previous check guarded against. BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds Write of size 4 ... by task exploit kasan_report (mm/kasan/report.c:595) ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833) calc_target (net/ceph/osd_client.c:1638) __submit_request (net/ceph/osd_client.c:2394) ceph_osdc_start_request (net/ceph/osd_client.c:2490) ceph_osdc_call (net/ceph/osd_client.c:5164) rbd_dev_image_probe (drivers/block/rbd.c:6899) do_rbd_add (drivers/block/rbd.c:7138) ... kernel BUG at net/ceph/osdmap.c:2670! [ idryomov: do the same in __decode_pg_upmap_items() ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-80527", "url": "https://ubuntu.com/security/CVE-2026-80527", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix hanging __ceph_get_caps() with stale mds_wanted A reader can hang forever in __ceph_get_caps() when the client no longer holds `FILE_RD`, but local cap state still says that the capability is already wanted (via `mds_wanted`). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke `FILE_RD` from the reader; the next read then has to reacquire `FILE_RD`. If the cap update that should request `FILE_RD` never reaches the MDS after `cap->mds_wanted` was raised, the reader is left holding only non-file caps while local `mds_wanted` still includes the file read caps. In that state, try_get_cap_refs() sees `need <= mds_wanted` and returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap update that was supposed to request `FILE_RD never reaches the MDS after `cap->mds_wanted was` raised, no further request is sent and the waiter can sleep indefinitely until unrelated cap traffic happens to wake it up. The ordering issue is that `cap->mds_wanted` is updated in __prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually queued for send. That makes one field serve two different meanings at once: what this client wants, and what the client believes the MDS already knows it wants. A proper fix would be to split those states and track whether a cap update is actually in flight or has been observed by the MDS. However, simply moving the `cap->mds_wanted assignment` later would not be sufficient: queueing the message in the messenger does not guarantee that the MDS processed that specific wanted set, and reconnect or message loss can still invalidate that assumption. Fixing that properly would require a larger rework of the cap state machine. To allow simpler backports to stable kernels, this patch implements a simpler workaround: - stop waiting forever in __ceph_get_caps(); after a bounded wait, fall back to the renew path - make ceph_renew_caps() issue a synchronous `OPEN` request whenever the inode still does not actually hold the wanted caps, instead of only calling ceph_check_caps() The extra issued-vs-wanted check in ceph_renew_caps() is necessary because the previous test only checked whether the inode still had any real caps at all. That is not enough after revocation: the client can still hold something like `pLs` and yet be missing `FILE_RD` completely. In that case, falling back to ceph_check_caps() is not sufficient, because it still trusts `cap->mds_wanted` and may resend nothing. By requiring `(issued & wanted) == wanted` before taking the asynchronous path, the code only uses ceph_check_caps() when the `wanted caps` are already actually issued. Otherwise, it sends the synchronous `OPEN` renew. This preserves the existing asynchronous fast path when the wanted caps are already issued, avoids changing cap-state semantics, and fixes the hang by guaranteeing that a stalled waiter eventually retries through a path that does not rely on the stale `mds_wanted` state. [ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to mds_client.h, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80528", "url": "https://ubuntu.com/security/CVE-2026-80528", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: avoid fs reclaim while using current->journal_info handle_reply() stores a `ceph_mds_request` pointer in `current->journal_info` while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in `current->journal_info` as a journal handle and dereferences the request's `r_tid` as `h_transaction`, causing a kernel crash, e.g.: Unable to handle kernel paging request at virtual address 00000000077b4818 [...] Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 6 UID: 0 PID: 2699135 Comm: kworker/6:3 Tainted: G W 6.18.38-i3 #1113 NONE [...] Workqueue: ceph-msgr ceph_con_workfn pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : jbd2__journal_start+0x2c/0x208 lr : __ext4_journal_start_sb+0x100/0x178 [...] Call trace: jbd2__journal_start+0x2c/0x208 (P) __ext4_journal_start_sb+0x100/0x178 ext4_dirty_inode+0x3c/0x90 __mark_inode_dirty+0x58/0x400 iput.part.0+0x2b0/0x370 iput+0x18/0x30 dentry_unlink_inode+0xc0/0x158 __dentry_kill+0x80/0x250 shrink_dentry_list+0x90/0x130 prune_dcache_sb+0x60/0x98 super_cache_scan+0xe8/0x190 do_shrink_slab+0x174/0x388 shrink_slab+0xd8/0x4c0 shrink_node+0x31c/0x908 do_try_to_free_pages+0xd0/0x508 try_to_free_pages+0x11c/0x238 __alloc_frozen_pages_noprof+0x4d0/0xdd0 __folio_alloc_noprof+0x18/0x70 __filemap_get_folio+0x248/0x440 ceph_readdir_prepopulate+0x570/0x9e8 mds_dispatch+0x1424/0x1ba0 ceph_con_process_message+0x74/0xa0 ceph_con_v1_try_read+0x3a0/0x1510 ceph_con_workfn+0x260/0x460 Enter a scoped NOFS allocation context and leave it after clearing `journal_info`. This prevents filesystem reclaim from recursing into another filesystem while the field contains Ceph-private data.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80529", "url": "https://ubuntu.com/security/CVE-2026-80529", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: don't swallow dquot recovery verification errors xlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80534", "url": "https://ubuntu.com/security/CVE-2026-80534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix ilock leak on error in xfs_dq_get_next_id xfs_dq_get_next_id() takes the quota inode ILOCK before calling xfs_iread_extents(). If xfs_iread_extents() fails, the function returns immediately without releasing the lock, leaking the quota inode ILOCK. This can leave the quota inode locked and cause subsequent quota operations to hang. Fix this by jumping to a common unlock path on error instead of returning directly.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80539", "url": "https://ubuntu.com/security/CVE-2026-80539", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: disallow multiple FENCE chunks in one submit amdgpu_cs_pass1() dispatches on chunk_id once per chunk without rejecting repeated ids. p->uf_bo is a single-slot field, so a submission carrying two AMDGPU_CHUNK_ID_FENCE chunks runs amdgpu_cs_p1_user_fence() twice, and the second run overwrites p->uf_bo with a freshly referenced BO without dropping the reference taken by the first. amdgpu_cs_parser_fini() only unrefs the final p->uf_bo, so every FENCE chunk but the last leaks a BO reference. The leaked BO outlives handle close and process exit. Reject duplicate FENCE chunks the same way commit fec5f8e8c6bc (\"drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit\") did for p->bo_list. (cherry picked from commit 665b1fc2a1845206408f9a2c6da67101789edb82)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80540", "url": "https://ubuntu.com/security/CVE-2026-80540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD decode image min size calculation This needs to use pitch instead of width. Also reject pitch over 4096 to avoid overflow. (cherry picked from commit b41c8cb12e202b220353332ab87dc01a11f69304)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80907", "url": "https://ubuntu.com/security/CVE-2026-80907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix UVD dpb min size calculation for H264 This should use actual number of references from the decode message, instead of maximum derived from level. (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80908", "url": "https://ubuntu.com/security/CVE-2026-80908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reject UVD message with dimensions above 4096 Fixes potential overflow in DPB size calculations. (cherry picked from commit 05e1387d151f71569fbe122d2c89f9db0c21dc10)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80541", "url": "https://ubuntu.com/security/CVE-2026-80541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate GEM_CREATE domain combinations AMDGPU_GEM_CREATE checked domain bits against AMDGPU_GEM_DOMAIN_MASK, but did not validate domain combinations. Userspace could combine CPU|GTT|VRAM with DOORBELL, GDS, GWS, or OA, making amdgpu_bo_placement_from_domain() exceed AMDGPU_BO_MAX_PLACEMENTS and hit BUG_ON(). Allow combinations only within CPU/GTT/VRAM, and require non-CPU/GTT/ VRAM domains to be specified one at a time. Return -EINVAL for invalid combinations in amdgpu_gem_create_ioctl(). v2: Rename helper from amdgpu_gem_domain_valid() to amdgpu_gem_are_domains_valid() (Christian) (cherry picked from commit db39852d0c39843cb02048dfb47e4b8c703e9080)", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80909", "url": "https://ubuntu.com/security/CVE-2026-80909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reject UVD message with invalid number of h265 refs Same change as for h264, avoids overflow later when calculating min dpb size. (cherry picked from commit a4b0720e4f1601f97f59a2be9c1b4b94fa6527d5)", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80548", "url": "https://ubuntu.com/security/CVE-2026-80548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Selectively expand io_mutex The io_mutex was defined to serialize the io_regions, but then has also sort of been associated with the I/O themselves because of the close relationship they share. With the handful of races that are possible, the choices are either to: A) expand the scope of io_mutex to close these remaining windows, or B) reduce the scope of io_mutex to just io_region, and introduce a new lock mechanism for the remaining I/O resources This patch implements A, since B brings with it a lot more interactions that would need to be tracked and kept in a correct hierarchy. It also takes advantage of the workqueue element for cp_free() that now gets called out of fsm_notoper(), which could be invoked out of an interrupt context and thus cannot acquire a mutex itself.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80549", "url": "https://ubuntu.com/security/CVE-2026-80549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Move cp cleanup out of not operational The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80550", "url": "https://ubuntu.com/security/CVE-2026-80550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Fix out of bounds check on CCW array The routine ccwchain_calc_length() counts the number of channel command words (CCWs) that are chained together in a single channel program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs. The loop itself is \"do..while (count < 257)\", and while the logic in is_cpa_within_range() correctly adjusts between the 0-index array of CCWs and the count of CCWs starting at 1, this means it would look at a possible 257th CCW before ending the loop and (correctly) returning an error. Fix this by restructuring the loop to break as soon as 256 CCWs (thus indexes 0-255) are examined, without looking at memory outside the range.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80552", "url": "https://ubuntu.com/security/CVE-2026-80552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure index for read/write regions are within range The introduction of the capability chain rightly clamped the region indexes to the range of the capabilities itself, but neglected to do so for the existing read/write regions which should also be enforced.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80553", "url": "https://ubuntu.com/security/CVE-2026-80553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Cancel existing workqueues The initialization of the io_work and crw_work workqueues begs the question of whether they should be un-initialized. Add the corresponding cleanup tags in _release_dev to ensure work isn't dispatched after the private struct is free'd.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80554", "url": "https://ubuntu.com/security/CVE-2026-80554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Limit the number of channel program segments The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program. The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.", "cve_priority": "high", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80558", "url": "https://ubuntu.com/security/CVE-2026-80558", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Avoid using invalid osd indices from primary_temp A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80559", "url": "https://ubuntu.com/security/CVE-2026-80559", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: sur40 - fix input device registration ordering In sur40_probe(), input_register_device() was previously called early before the V4L2 video device and vb2_queue components were fully initialized. If userspace opened the input device immediately upon registration, sur40_open() would trigger and start the sur40_poll() worker thread. This worker thread invokes sur40_process_video() and accesses the uninitialized vb2_queue structure, leading to a data race and potential system crash. Furthermore, if V4L2 or video registration failed after input_register_device() succeeded, the error path fell through to calling input_free_device() on a successfully registered device instead of input_unregister_device(), corrupting input core state. Move input_register_device() to the very end of sur40_probe(). This ensures the V4L2 and video queue structures are fully initialized before polling can start, and naturally resolves the error path bug since input_free_device() is now only called when input registration has not yet occurred. To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move input_unregister_device() to the very beginning of sur40_disconnect(). This guarantees that the input polling worker thread is stopped before V4L2 video components or control handlers are unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80560", "url": "https://ubuntu.com/security/CVE-2026-80560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openrisc: signal: do not restore privileged SR bits on sigreturn restore_sigcontext() copies the whole supervision register (SR) from the signal frame and only clears SPR_SR_SM before the value is reloaded into the hardware SR (through ESR and l.rfe) on the return to user space. All other SR bits are left under user control. An unprivileged task can thus return from a signal handler through a crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the CPU performs no translation or protection on data accesses, so the task gains read and write access to arbitrary physical memory, a local privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH and the cache-enable bits are exposed the same way. The ptrace GPR regset already refuses any change to SR for exactly this reason. Restore only the arithmetic flag bits (F, CY, OV) from the signal frame and take every privileged control bit from the SR the kernel saved on signal entry. Verified with qemu-system-or1k -M or1k-sim: before this change an unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the same PoC receives SIGSEGV and physical memory is unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80561", "url": "https://ubuntu.com/security/CVE-2026-80561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix multiple unsafe decodes in decode_locker() decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ]", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80565", "url": "https://ubuntu.com/security/CVE-2026-80565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix error path in devm_qce_register_algs If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80566", "url": "https://ubuntu.com/security/CVE-2026-80566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: hynitron_cstxxx - validate touch count and finger IDs The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80567", "url": "https://ubuntu.com/security/CVE-2026-80567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80568", "url": "https://ubuntu.com/security/CVE-2026-80568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - block s_input when F54 queue is busy Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming).", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80569", "url": "https://ubuntu.com/security/CVE-2026-80569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): \treport_size = rmi_f54_get_report_size(f54); \t... \tfor (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { \t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i); \t\t... \t\trmi_read_block(.., f54->report_data + i, size); \t} report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80570", "url": "https://ubuntu.com/security/CVE-2026-80570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80573", "url": "https://ubuntu.com/security/CVE-2026-80573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - validate input packet lengths iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80752", "url": "https://ubuntu.com/security/CVE-2026-80752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: psxpad-spi - set driver data before use psxpad_spi_suspend() retrieves the controller state with spi_get_drvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80574", "url": "https://ubuntu.com/security/CVE-2026-80574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1].", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80754", "url": "https://ubuntu.com/security/CVE-2026-80754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix F55 transmitter electrode count typo During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80578", "url": "https://ubuntu.com/security/CVE-2026-80578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80910", "url": "https://ubuntu.com/security/CVE-2026-80910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses EAR SPKR PA Gain\" and the four \"WSA RX* Mux\" controls are enumerated, but their get and put callbacks access the value through ucontrol->value.integer.value[0] (a long) instead of ucontrol->value.enumerated.item[0] (an unsigned int). This same pattern was fixed in the sibling drivers by commit bcfe5f76cc40 (\"ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type\") and commit 0ea5eff7c606 (\"ASoC: codecs: va-macro: fix accessing array out of bounds for enum type\"), but wsa-macro was missed. On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value sanity check and every read of these controls fails with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80911", "url": "https://ubuntu.com/security/CVE-2026-80911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80584", "url": "https://ubuntu.com/security/CVE-2026-80584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: validate user buffer length in SNMP and ARP query ioctls qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by a user-supplied length (udata_len) without checking a lower bound, then set udata_offset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with if ((udata_len - udata_offset) < len) Both fields are u32, so a udata_len smaller than udata_offset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from kzalloc(), which the existing NULL check does not catch. Reject buffers smaller than udata_offset before allocating, so the callback subtraction can no longer underflow.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80585", "url": "https://ubuntu.com/security/CVE-2026-80585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fastopen: only mark MPTFO subflows with SYN data Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really \"doing TFO\".", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80586", "url": "https://ubuntu.com/security/CVE-2026-80586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80587", "url": "https://ubuntu.com/security/CVE-2026-80587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: avoid combining some incoming suboptions Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A few points of attention: - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch. - In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption. - In mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MP_CAPABLE. Similarly, even if there is room, a DSS cannot be used with an MP_JOIN.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-80912", "url": "https://ubuntu.com/security/CVE-2026-80912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject an unclaimed class value in security_get_classes() security_get_classes() sizes an array by p_classes.nprim and fills it at value - 1, so a class value the policy never defines leaves a NULL. sel_make_classes() passes every entry to sel_make_dir(), reaching the same d_alloc_name() dereference as the permission array. The class symbol table is allowed to be sparse (policydb_class_isvalid() exists to absorb that), but this getter builds its own array straight from the hash table and has no such predicate. Fail the lookup when a value went unclaimed instead of handing out the NULL. Conforming policies define every class they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2026-80756", "url": "https://ubuntu.com/security/CVE-2026-80756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: do not cancel a policy conversion that never started sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes() fails, and that helper dereferences the outgoing policy to cancel its sidtab conversion. On the first policy load there is no outgoing policy: security_load_policy() returns early for that case, before it converts anything, and state->policy is still NULL. A first load that fails while building the selinuxfs tree therefore takes a NULL dereference in selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load. Skip the cancel when there is no old policy, mirroring the check security_load_policy() already makes before it converts.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80757", "url": "https://ubuntu.com/security/CVE-2026-80757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: reject a class permission count below its inherited common security_get_permissions() maps an inherited common's permissions into an array sized by the class's own permissions.nprim, but class_read() takes that nprim verbatim from the policy image and never checks that it covers the common. A class that inherits a common of N permissions while declaring a smaller nprim is accepted, and on load the common's permissions are written past the class-sized array -- an out-of-bounds heap write. Reject a class whose permission count is below its inherited common's. Well-formed policies, where the class count already includes the inherited permissions, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-80913", "url": "https://ubuntu.com/security/CVE-2026-80913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: selinux: require every boolean value to be defined p_bools.nprim comes from the policy image independently of how many booleans follow it, and cond_index_bool() fills bool_val_to_struct[] at value - 1, so a count larger than the values present leaves NULL entries. Every user of that array then walks it by index and dereferences each entry: cond_evaluate_expr() on the access-vector path, security_get_bools() and security_get_bool_value() behind selinuxfs, and security_set_bools(). A sparse class value is absorbed by policydb_class_isvalid() and its siblings; booleans have no such predicate, and no consumer that could use one. Reject a boolean value that no boolean defines, once, where the array is built. Conforming policies define every boolean they declare and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:18:00 UTC" }, { "cve": "CVE-2025-40054", "url": "https://ubuntu.com/security/CVE-2025-40054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF issue in f2fs_merge_page_bio() As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list \t\t\t\t\t\twrite \t\t\t\t\t\t- f2fs_write_begin \t\t\t\t\t\t: write page #1 \t\t\t\t\t\t - f2fs_folio_wait_writeback \t\t\t\t\t\t - f2fs_submit_merged_ipu_write \t\t\t\t\t\t - f2fs_submit_write_bio \t\t\t\t\t\t : submit bio which inclues page #1 and #2 \t\t\t\t\t\tsoftware IRQ \t\t\t\t\t\t- f2fs_write_end_io \t\t\t\t\t\t - fscrypt_free_bounce_page \t\t\t\t\t\t : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\ -c \"pwrite 0 32k\" -c \"fdatasync\" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\ -c \"pwrite 0 32k\" -c \"fdatasync\" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-80589", "url": "https://ubuntu.com/security/CVE-2026-80589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: stop the timeout timer when releasing a never added disk disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d (\"block: simplify disk shutdown\") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.", "cve_priority": "medium", "cve_public_date": "2026-08-26 15:17:00 UTC" }, { "cve": "CVE-2026-74585", "url": "https://ubuntu.com/security/CVE-2026-74585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound the DROM dual link port number before indexing sw->ports tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74586", "url": "https://ubuntu.com/security/CVE-2026-74586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear new_transport when removing a peer sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, src_out_of_asoc_ok keeps this HEARTBEAT on control_chunk_list. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state. The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel: BUG: KASAN: slab-use-after-free in sctp_outq_select_transport Read of size 4 at addr ffff88800b9bd95c by task python3/197 Call Trace: sctp_outq_select_transport+0x549/0x8b0 [sctp] sctp_outq_flush+0x306/0x2c60 [sctp] sctp_transport_immediate_rtx+0xaf/0x260 [sctp] sctp_process_asconf_ack+0xa48/0xf70 [sctp] Allocated by task 197: sctp_transport_new+0x68/0x650 [sctp] sctp_assoc_add_peer+0x258/0x12a0 [sctp] sctp_process_asconf+0x5e9/0x1090 [sctp] Last potentially related work creation: __call_rcu_common.constprop.0+0x77/0xb70 sctp_assoc_del_nonprimary_peers+0x7c/0xd0 [sctp] sctp_process_asconf+0xd9c/0x1090 [sctp] The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops. Clear new_transport when its peer is removed, before it can be used to create the HEARTBEAT.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74587", "url": "https://ubuntu.com/security/CVE-2026-74587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix use-after-free of cached ASCONF chunk addip_last_asconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer. However, sctp_asconf_queue_teardown() releases the cached chunk without clearing addip_last_asconf. During peer restart handling, sctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes sctp_asconf_queue_teardown() while the association remains alive and leaves the pointer dangling. A delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(), which accesses the stale chunk and passes it to sctp_process_asconf_ack(), causing a use-after-free and a second release. Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses timer_delete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctp_sf_t4_timer_expire() after the purge and dereference NULL. Clear addip_last_asconf after releasing the cached chunk, and make sctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding ASCONF remains.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74588", "url": "https://ubuntu.com/security/CVE-2026-74588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: \tif (chunk->tsn_gap_acked) { \t\tlist_move_tail(&chunk->transmitted_list, \t\t\t &transport->transmitted); \t\tcontinue; \t} The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches \ttchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74589", "url": "https://ubuntu.com/security/CVE-2026-74589", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix sk_redir use-after-free in send verdict sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer: CPU 0 CPU 1 sk_redir = psock->sk_redir apply_bytes remains nonzero release_sock(sk) lock_sock(sk) apply_bytes reaches zero psock->sk_redir = NULL release_sock(sk) tcp_bpf_sendmsg_redir(sk_redir) sock_put(sk_redir) tcp_bpf_sendmsg_redir(sk_redir) The final sock_put() can free sk_redir before CPU 0 dereferences it. KASAN reported: BUG: KASAN: slab-use-after-free in tcp_bpf_sendmsg_redir+0xf39/0x1020 Read of size 8 at addr ffff888108537090 by task poc/87 Call Trace: tcp_bpf_sendmsg_redir+0xf39/0x1020 tcp_bpf_sendmsg+0x977/0x1a50 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 85: sk_prot_alloc+0x56/0x210 sk_clone+0x6f/0x14b0 inet_csk_clone_lock+0x24/0x740 tcp_create_openreq_child+0x25/0x2710 tcp_v4_syn_recv_sock+0x10a/0xe00 Freed by task 0: __kasan_slab_free+0x43/0x70 slab_free_after_rcu_debug+0xa6/0x1e0 rcu_core+0x50a/0x1850 Last potentially related work creation: __sk_destruct+0x3da/0x540 sk_psock_destroy+0x81e/0xab0 process_one_work+0x63a/0x1070 Take a temporary socket reference while the source socket lock still protects psock->sk_redir, and drop it after tcp_bpf_sendmsg_redir() returns. This keeps each unlocked use independent of cached-verdict ownership.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74594", "url": "https://ubuntu.com/security/CVE-2026-74594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/psi: Shut down rtpoll_timer in psi_cgroup_free() psi_schedule_rtpoll_work() is called locklessly from the scheduler hotpath and can race psi_trigger_destroy() taking down the last rtpoll trigger under rtpoll_trigger_lock: psi_schedule_rtpoll_work() psi_trigger_destroy() rcu_read_lock(); task = rcu_dereference(rtpoll_task); rcu_assign_pointer(rtpoll_task, NULL); timer_delete(&rtpoll_timer); mod_timer(&rtpoll_timer, ...); rcu_read_unlock(); synchronize_rcu(); kthread_stop(task_to_destroy); The group can then be freed with the re-armed timer still pending, and poll_timer_fn() runs on freed memory. 461daba06bdc (\"psi: eliminate kthread_worker from psi trigger scheduling mechanism\") deleted the timer synchronously after the synchronize_rcu(), which prevented this but raced trigger creation instead: the deletion could cancel the timer that a new trigger set armed during the grace period and, as creation also reinitialized the timer at the time, corrupt it. 8f91efd870ea (\"psi: Fix race between psi_trigger_create/destroy\") moved the initialization into group_init() and the deletion into the locked section, trading the creation races for the window above. Neither placement in the destruction path works. A pending timer firing while the group is alive is harmless though. poll_timer_fn() just wakes the rtpoll waitqueue and doesn't re-arm itself. Bind the timer to the group's lifetime instead and shut it down in psi_cgroup_free(). Nothing can arm it by then. timer_shutdown_sync() because the timer is never armed again.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74595", "url": "https://ubuntu.com/security/CVE-2026-74595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74597", "url": "https://ubuntu.com/security/CVE-2026-74597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip6ip6_err() ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6_send(). The clone still carries the outer packet's inet6_skb_parm in skb->cb. If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skb_pull(). icmpv6_send() later calls mip6_addr_swap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skb_shared_info. Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74598", "url": "https://ubuntu.com/security/CVE-2026-74598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fix Route Information option length validation rt6_route_rcv() validates the Route Information option (RFC 4191) length against the prefix length, but both checks are off by one. rinfo->length is the ND option length in units of 8 octets and it *includes* the 8-byte option header, so an option carrying N bytes of prefix has length == 1 + N/8. RFC 4191 section 2.3 requires length 3 when Prefix Length is greater than 64, and 2 or 3 when it is greater than 0. The code accepts length >= 2 and length >= 1 respectively. ipv6_addr_prefix() then copies prefix_len/8 bytes out of rinfo->prefix, so a Router Advertisement with (prefix_len=128, length=2) or (prefix_len=64, length=1) makes the kernel read up to 8 bytes past the end of the option. Those bytes end up in the prefix of the route that gets installed, so they are visible to userspace: # RA with a Route Information option (prefix_len=128, length=2) # followed by a source link-layer address option, 01 01 de ad be ef ca fe $ ip -6 route show 2001:db8:dead:beef:101:dead:beef:cafe via fe80::1234 dev veth0 proto ra ^^^^^^^^^^^^^^^^^^ the next option, read out of bounds When the Route Information option is the last one in the packet, those eight bytes come from the skb tail room instead. Reject the option lengths RFC 4191 does not allow.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74603", "url": "https://ubuntu.com/security/CVE-2026-74603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix board ID over-read The EEPROM board ID is a fixed 13-byte field and is not guaranteed to contain a NUL terminator. Passing it directly to devlink_info_version_fixed_put() treats it as a C string and may read beyond the field. Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer before reporting the ID. Use a precision limit because the snprintf() output size alone does not bound the source string scan.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74604", "url": "https://ubuntu.com/security/CVE-2026-74604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\" Revert commit 030a48b0f6ce (\"thermal/drivers/hwmon: Cleanup coding style a bit\") that introduced a use-after-free into the error path of thermal_add_hwmon_sysfs() by removing a valid check from it.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74606", "url": "https://ubuntu.com/security/CVE-2026-74606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec() eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running. Use list_for_each_entry_safe() to save the next sibling before recursively removing the current child.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80726", "url": "https://ubuntu.com/security/CVE-2026-80726", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74608", "url": "https://ubuntu.com/security/CVE-2026-74608", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_try_adding_channels() cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory. Increment weight_fulfilled before dropping the temporary reference, keeping iface alive for the final access.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74609", "url": "https://ubuntu.com/security/CVE-2026-74609", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down() tipc_node_link_down() caches the link pointer before taking n->lock: \tstruct tipc_link *l = le->link;\t\t/* unlocked */ \tif (!l) \t\treturn; \ttipc_node_write_lock(n); \tif (!tipc_link_is_establishing(l)) {\t/* deref l */ \t... \t\ttipc_link_reset(l);\t\t/* write into l */ \tif (delete) { \t\tkfree(l); \t\tle->link = NULL; The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it: - CPU A, delete=false: tipc_rcv() on TIPC_LINK_DOWN_EVT, or the link supervision timer via tipc_node_timeout(), reads l unlocked and then dereferences it under n->lock; - CPU B, delete=true: netlink TIPC_NL_BEARER_DISABLE -> bearer_disable() -> tipc_node_delete_links() -> tipc_node_link_down(n, bearer_id, true) -> kfree(l). The link is freed with plain kfree(), not kfree_rcu(), and for UDP bearers disable_media() only schedules the asynchronous cleanup_bearer() work, so its synchronize_net() runs after the links are already gone. An in-flight CPU A that has read l therefore dereferences freed memory once B frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch. The following trace was captured on 7.2.0-rc5-00284-gaf39eb111ce6: BUG: KASAN: slab-use-after-free in tipc_link_is_establishing (net/tipc/link.c:285) Read of size 4 at addr ffff88802e2aa068 by task swapper/2/0 tipc_link_is_establishing (net/tipc/link.c:285) tipc_node_link_down (net/tipc/node.c:1076) tipc_node_timeout (net/tipc/node.c:843) Allocated by task 9549: tipc_link_create (net/tipc/link.c:490) tipc_node_check_dest (net/tipc/node.c:1279) tipc_disc_rcv (net/tipc/discover.c:252) tipc_udp_recv (net/tipc/udp_media.c:389) Freed by task 9549: tipc_node_link_down (net/tipc/node.c:1084) tipc_node_delete_links (net/tipc/node.c:1320) bearer_disable (net/tipc/bearer.c:414) __tipc_nl_bearer_disable (net/tipc/bearer.c:992) Move the le->link read inside tipc_node_write_lock(), so it is serialised against the kfree() in the delete path. A racing teardown now either has not run yet, and we see a valid link, or has already run, and we see NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74610", "url": "https://ubuntu.com/security/CVE-2026-74610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: don't leave a full plaintext sk_msg ring unpushed When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist. An unprivileged user can trigger this on a loopback TCP socket with the \"tls\" ULP attached: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0 Call Trace: skcipher_walk_next+0x1d1/0x2c0 gcm_encrypt_aesni_avx+0x1e9/0x220 bpf_exec_tx_verdict+0x3bb/0x860 tls_sw_sendmsg+0xa1a/0xca0 __sys_sendto+0x1da/0x1f0 Set full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74580", "url": "https://ubuntu.com/security/CVE-2026-74580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: reset the vring metadata cache on vring reconfiguration vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated: \tif (vhost_vq_meta_fetch(vq, addr, len, type)) \t\treturn true; The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vq_access_ok() and vq_log_used_access_ok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vq_meta_prefetch() hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps translating through the old mapping as \tmap->addr + addr - map->start for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlb_access_ok()'s slow path.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74612", "url": "https://ubuntu.com/security/CVE-2026-74612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: fix skb length accounting after XDP frag adjustment veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. The copied bytes included the affected skb's nr_frags, xdp_frags_size, and a kernel pointer from skb_shinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end. Subtract the old data_len before replacing it and add the new data_len afterwards, keeping skb->len and skb->data_len synchronized. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present. The skb is then still non-linear, so the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT(). Use skb_set_tail_pointer() and update skb->len explicitly instead, following bpf_prog_run_generic_xdp(). Unlike __skb_put(), skb_set_tail_pointer() does not require a linear skb. A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpf_xdp_pull_data() with frags still present; the old code triggers SKB_LINEAR_ASSERT(), while this fix passes 10/10 runs.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74613", "url": "https://ubuntu.com/security/CVE-2026-74613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: avoid refilling the RX queue after teardown Commit b917507e5ad9 (\"vsock/virtio: stop workers during the .remove()\") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. BUG: KASAN: slab-use-after-free in virtqueue_add_sgs Read of size 4 by task kworker/0:1 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2796) virtio_vsock_rx_fill (net/vmw_vsock/virtio_transport.c:332) virtio_transport_rx_work (net/vmw_vsock/virtio_transport.c:701) process_one_work (kernel/workqueue.c:3314) worker_thread (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 141: kfree (mm/slub.c:6566) vp_del_vq (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtio_vsock_freeze (net/vmw_vsock/virtio_transport.c:912) virtio_device_freeze (drivers/virtio/virtio.c:658) virtio_pci_freeze (drivers/virtio/virtio_pci_common.c:601) pci_pm_freeze (drivers/pci/pci-driver.c:1098) device_suspend (drivers/base/power/main.c:1968) Kernel panic - not syncing: KASAN: panic_on_warn set ... Jump to a no-refill exit when rx_run is clear, leaving the normal exit to replenish a running queue.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74614", "url": "https://ubuntu.com/security/CVE-2026-74614", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: read virtqueues under worker locks Commit bd50c5dc182b (\"vsock/virtio: add support for device suspend/resume\") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue. Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74615", "url": "https://ubuntu.com/security/CVE-2026-74615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one: \tif (conf.age_interval != vxlan->cfg.age_interval) \t\tmod_timer(&vxlan->age_timer, jiffies); There is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a member of struct vxlan_dev, so free_netdev() releases the allocation the timer lives in while it is still queued on a timer_base. expire_timers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 __asan_store8+0x84/0xac __run_timers+0x208/0x654 run_timer_softirq+0x154/0x18c Allocated by task 189: alloc_netdev_mqs+0x64/0x720 rtnl_create_link+0x4ac/0x520 rtnl_newlink+0x758/0xd00 Freed by task 191: netdev_release+0x40/0x58 netdev_run_todo+0x4a4/0x8c0 rtnl_dellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlan_cleanup() returns early on !netif_running(), and vxlan_open() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74616", "url": "https://ubuntu.com/security/CVE-2026-74616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xdp: reject clones that overrun skb_shared_info tailroom xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74619", "url": "https://ubuntu.com/security/CVE-2026-74619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen(\"overlay\") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74620", "url": "https://ubuntu.com/security/CVE-2026-74620", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: \tif (!opcode) \t\tret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b (\"net: sched: refactor reinsert action\"), after both goto-chain guards were written: commit 9469f375ab09 (\"net/sched: act_gact: disallow 'goto chain' on fallback control action\") and commit c08f5ed5d625 (\"net/sched: act_police: disallow 'goto chain' on fallback control action\"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74621", "url": "https://ubuntu.com/security/CVE-2026-74621", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix sk_buff leak when the header checks reject a packet tcf_ct_handle_fragments() runs its header sanity checks before handing anything to the defragmentation engine: \tif (family == NFPROTO_IPV4) \t\terr = tcf_ct_ipv4_is_fragment(skb, &frag); \telse \t\terr = tcf_ct_ipv6_is_fragment(skb, &frag); \tif (err || !frag) \t\treturn err; tcf_ct_ipv4_is_fragment() returns -EINVAL or -ENOMEM; tcf_ct_ipv6_is_fragment() adds -EPROTO when ipv6_find_hdr() fails. None of them frees or queues the skb, so on that path the caller still owns it. tcf_ct_act() however funnels every non-zero return into the ownership-transfer exit: \terr = tcf_ct_handle_fragments(net, skb, family, p->zone, &defrag); \tif (err) \t\tgoto out_frag; \t... out_frag: \tif (err != -EINPROGRESS) \t\ttcf_action_inc_drop_qstats(&c->common); \treturn TC_ACT_CONSUMED; TC_ACT_CONSUMED means the action took ownership of the skb, so no caller frees it - sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for that verdict. The skb is therefore orphaned: one sk_buff plus its data buffer is leaked per malformed packet, unbounded. Note the drop counter is already incremented for these errors, so the statistics claim a drop that never happens. Three different ownership states reach out_frag: today - the skb may be queued by the defrag engine (-EINPROGRESS), already freed by nf_ct_handle_fragments(), or still owned by us. Tell the caller which of those it is, and free the packet ourselves in the last case, which restores the TC_ACT_SHOT behaviour that predated the Fixes: commit. Reproduced on v7.2-rc6 with a 54-byte frame carrying a 40-byte IPv6 header with nexthdr = 0 (hop-by-hop) and nothing after it, on a clsact ingress chain with \"action ct\". kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet; with this patch it reports none.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74622", "url": "https://ubuntu.com/security/CVE-2026-74622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74623", "url": "https://ubuntu.com/security/CVE-2026-74623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and \"page_pool_release_retry() stalled pool shutdown\" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74624", "url": "https://ubuntu.com/security/CVE-2026-74624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: defer invalid log until after unlock TCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held. When invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock. Defer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking. Do the same for the SCTP invalid state-transition log that can be reached while ct->lock is held. Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74625", "url": "https://ubuntu.com/security/CVE-2026-74625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: release template ct on non-IP path A bridge nftables ct zone set rule can attach a conntrack template to an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6 EtherTypes, nf_ct_bridge_pre() currently overwrites skb->_nfct with IP_CT_UNTRACKED without releasing the existing template reference. That makes the per-cpu template, and any temporary templates allocated for concurrent use, unreachable and leaks memory until the host runs out of slab. Reset the skb conntrack state before marking the frame untracked so the existing template reference is dropped on the non-IP path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74630", "url": "https://ubuntu.com/security/CVE-2026-74630", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent in6_dev_get() from resurrecting inet6_dev in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3) kernel reproduced the invalid reference acquisition as UID 1000: refcount_t: addition on 0; use-after-free. ip6_mc_source+0xef4/0x17e0 It was followed by the corresponding reference underflow in ip6_mc_source(). The supplied trace from the same unpatched revision additionally shows the access after the RCU read-side section ends: BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0 Write of size 8 at addr ffff888015b50240 by task poc/1219 Bug found and triaged by OpenAI Security Research and validated by Trail of Bits.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74631", "url": "https://ubuntu.com/security/CVE-2026-74631", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: smc: fix splice entry lifetime imbalance in smc_rx_splice smc_rx_splice() passes pages to splice_to_pipe() before taking the references that cover the lifetime of each splice entry. In the VM-backed RMB path, splice_to_pipe() may drop unqueued entries through smc_rx_spd_release(), while queued entries are released later via the pipe buffer callback. The old post-splice accounting also derives the number of queued VM pages from an offset mutated while building the descriptor, and a multi-page splice pairs one sock_hold() with multiple sock_put() calls. Take the page and socket references for every candidate entry before splice_to_pipe(), and drop the matching private state, page reference, and socket reference from smc_rx_spd_release() for entries that never get queued. This fixes a refcount imbalance that can underflow page refcounts and trigger a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74635", "url": "https://ubuntu.com/security/CVE-2026-74635", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_cursor() bit_cursor() fetches the glyph under the cursor with \tc = scr_readw(vc_pos); \tsrc = vc_font.data + ((c & charmask) * w * height); where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count. Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c. When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access. BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr ffff800086c57970 Call Trace: soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365 fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427 hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883 update_region+0x100/0x18c drivers/tty/vt/vt.c:669 vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685 bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata. The fix completes the bounds checking started in commit 18c4ef4e765a (\"fbdev: bitblit: bound-check glyph index in bit_putcs*\"), which missed the cursor path. This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74636", "url": "https://ubuntu.com/security/CVE-2026-74636", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and, event_define_fields The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74641", "url": "https://ubuntu.com/security/CVE-2026-74641", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: bound the hwdep mmap fault offset snd_us428ctls_vm_fault() turns the faulting page offset into a kernel address with no bound of any kind: \toffset = vmf->pgoff << PAGE_SHIFT; \tvaddr = (char *)(...)->us428ctls_sharedmem + offset; \tpage = virt_to_page(vaddr); \tget_page(page); \tvmf->page = page; \treturn 0; snd_us428ctls_mmap() checks only the length of the mapping, never the offset, and us428ctls_sharedmem is a single page from alloc_pages_exact(). For a character device file_mmap_size_max() returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page offset above zero resolves to a struct page outside the object, and the handler installs it into the caller's address space read-write; the vma is not marked read-only. The caller picks the page frame with a single mmap() argument and gets read-write access to a page of kernel memory it does not own; an offset that lands in an unpopulated vmemmap region oopses instead. A process that can open the hwdep node of an attached US-X2Y reaches this after loading the FPGA image through the same node; no capability check is involved. On 7.2.0-rc5 (arm64), mmap() with a large offset: Unable to handle kernel paging request at virtual address fffffdffc45d5ac8 pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] Call trace: snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y] __do_fault __handle_mm_fault handle_mm_fault el0_da Reject any offset outside the shared region. The pcm hwdep handler in usx2yhwdeppcm.c computes its address the same way and needs the same bound. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80730", "url": "https://ubuntu.com/security/CVE-2026-80730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix crash passing ERR_PTR to kthread_stop() In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that hold an ERR_PTR. rb_threads[] is static, so unassigned slots are NULL. But when kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free. That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall self-test. crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74646", "url": "https://ubuntu.com/security/CVE-2026-74646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else. Take fl->lock around the move, matching every other fl->mmaps accessor.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74647", "url": "https://ubuntu.com/security/CVE-2026-74647", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Remove buffer from list prior to unmap operation fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing. Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74648", "url": "https://ubuntu.com/security/CVE-2026-74648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: validate monitor transmit frame lengths rtw_cfg80211_monitor_if_xmit_entry() removes the radiotap header and then reads the 802.11 frame control field without checking that a base 802.11 header remains. The data path also pulls the calculated 802.11, QoS and SNAP header span before confirming that the skb contains it. A truncated frame can therefore cause out-of-bounds reads or leave insufficient data for the Ethernet address writes. Reject frames that do not contain the base 802.11 header and data frames that do not contain their complete calculated header span.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74649", "url": "https://ubuntu.com/security/CVE-2026-74649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix missing shared-key auth challenge length check The WEP shared-key authentication handler uses the challenge-text element's attacker-controlled length without checking it against the fixed 128-byte chg_txt buffer. In OnAuthClient() the length from rtw_get_ie() - up to 255 - is used to perform memcpy() into the 128-byte pmlmeinfo->chg_txt, so a malicious AP sending a malformed WLAN_EID_CHALLENGE element can overflow/underfill chg_txt by up to 127 bytes. It is reachable over the air, before association, during shared-key authentication. In the case of an overflow, the driver can write out of bounds. In the case of an underfill, the driver can echo stale buffer memory. The challenge text is defined to be exactly 128 octets, which is already provided as the WLAN_AUTH_CHALLENGE_LEN define; require the element to be exactly that length before use.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74650", "url": "https://ubuntu.com/security/CVE-2026-74650", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in WMM_param_handler() WMM_param_handler() copies a fixed-size WMM parameter element out of a received information element without checking that the element is long enough, causing an out-of-bounds read for a short WMM IE. The handler reads sizeof(struct WMM_para_element) (18) bytes at pIE->data + 6, so it requires pIE->length to be at least 24 (WLAN_WMM_LEN), but it never validates the length. Two of its three callers reach it after matching only the WMM OUI: OnAssocRsp() in rtw_mlme_ext.c matches a 6-byte OUI, and join_cmd_hdl() matches a 4-byte OUI, before calling the handler. A vendor-specific IE carrying the WMM OUI but a length between 6 and 23, placed in an association response or in the IE blob handed to join_cmd_hdl(), passes the OUI check and then makes the memcmp() and memcpy() at pIE->data + 6 read past the end of the element. OnAssocRsp() parses a frame received from the AP, so this is reachable from a remote peer. The remaining caller in rtw_wlan_util.c already guards the handler with \"pIE->length == WLAN_WMM_LEN\". Move the equivalent check into the handler itself so every caller is covered; the sibling IE handlers in the same parsing loop (HT_caps_handler(), HT_info_handler(), ERP_IE_handler()) likewise bound their accesses by pIE->length.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74651", "url": "https://ubuntu.com/security/CVE-2026-74651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie() rtw_get_wpa_ie() reads bytes at fixed offsets into a vendor-specific information element without checking that the element is long enough, causing an out-of-bounds read for a short trailing IE. The function locates a vendor-specific IE (EID 221) with rtw_get_ie() and then compares a 4-byte OUI+type at pbuf + 2 and reads a 2-byte version word at pbuf + 6. Those accesses require the IE body to be at least 6 bytes, but rtw_get_ie() only guarantees that the element fits within the buffer; it does not enforce a minimum body length. A vendor-specific IE whose length byte is 0 to 5, placed at the end of the buffer, therefore makes these reads run past the end of the IE and past the end of the buffer itself. The buffer holds information elements taken from received management frames and from the IE blob passed to rtw_cfg80211_set_wpa_ie(), which is kmemdup'd to its exact length, so the read can run off the end of the allocation. The sibling helpers rtw_get_sec_ie(), rtw_get_wapi_ie() and rtw_get_wps_ie() in this file already reject too-short vendor-specific IEs before their OUI memcmp(); rtw_get_wpa_ie() was never brought in line with them, and needs a minimum of 6 rather than 4 bytes because of the version word. Add the missing length check.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74654", "url": "https://ubuntu.com/security/CVE-2026-74654", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 (\"serial: 8250_dw: Ensure BUSY is deasserted\") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74656", "url": "https://ubuntu.com/security/CVE-2026-74656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 CPU 1 fib_nhc_update_mtu() update_or_create_fnhe() load fnhe spin_lock_bh(&fnhe_lock) fnhe_remove_oldest() unlink fnhe kfree_rcu(fnhe, rcu) access fnhe after grace period KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fib_nhc_update_mtu+0x3df/0x410 fib_sync_mtu+0x7a/0xd0 fib_netdev_event+0x229/0x3f0 netif_set_mtu_ext+0x33a/0x570 dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74657", "url": "https://ubuntu.com/security/CVE-2026-74657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops fib_nlmsg_size() still estimates nexthop space as if every gateway is encoded as an IPv4 RTA_GATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fib_nexthop_info() dumps as RTA_VIA. As a result, route notifications can allocate an skb that is too small. fib_dump_info() then fails with -EMSGSIZE and rtmsg_fib() hits the WARN_ON() that marks such failures as a fib_nlmsg_size() bug. With panic_on_warn set, this becomes a kernel panic. Mirror the actual nexthop dump layout in fib_nlmsg_size(): account for IPv6 nexthop gateways dumped as RTA_VIA, for the no-header rtnexthop layout used inside RTA_MULTIPATH, and for RTA_FLOW only when it is actually present.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74658", "url": "https://ubuntu.com/security/CVE-2026-74658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 (\"futex: Prevent robust futex exit race\"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 (\"futex: Add support for unlocking robust futexes\") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74514", "url": "https://ubuntu.com/security/CVE-2026-74514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix memory accounting for pinned/unpinned pages The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. [borntraeger@linux.ibm.com: Fixed whitespace]", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74659", "url": "https://ubuntu.com/security/CVE-2026-74659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with \tsub_tlv = skb_put(skb, sizeof(*sub_tlv)); \tsub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74660", "url": "https://ubuntu.com/security/CVE-2026-74660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebt_nflog: pin the NFLOG backend nf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends. An ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving is: CPU 0 CPU 1 nfnetlink_log_fini() unregister_pernet_subsys() kfree(nfnl_log_pernet(net)) ebt_nflog_tg() nf_log_packet() nfulnl_log_packet() instance_lookup_get_rcu() The global ULOG logger is still registered at this point, so CPU 1 dereferences the per-net state after CPU 0 has freed it. KASAN reported: BUG: KASAN: slab-use-after-free in instance_lookup_get_rcu Read of size 8 at addr ff110001052e6210 by task poc/92 Call Trace: instance_lookup_get_rcu+0x1ce/0x1f0 [nfnetlink_log] nfulnl_log_packet+0x248/0x2fb0 [nfnetlink_log] nf_log_packet+0x204/0x300 ebt_nflog_tg+0x351/0x550 ebt_do_table+0xedf/0x22b0 Allocated by task 90: __kmalloc_noprof+0x186/0x470 ops_init+0x6d/0x420 register_pernet_operations+0x2f6/0x670 register_pernet_subsys+0x23/0x40 Freed by task 93: kfree+0x131/0x3c0 ops_undo_list+0x3e3/0x700 unregister_pernet_operations+0x232/0x490 unregister_pernet_subsys+0x1c/0x30 nfnetlink_log_fini+0x34/0x450 [nfnetlink_log] Acquire the ULOG logger module reference when an ebt_nflog rule is validated and release it when the rule is destroyed. Request the NFLOG backend for legacy callers when needed, matching xt_NFLOG. This prevents module teardown until all ebt_nflog rules have stopped using the logger.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74661", "url": "https://ubuntu.com/security/CVE-2026-74661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: fix netdev use-after-free in beacon worker mac802154_beacon_worker() reads local->beacon_req under RCU and derives the sub-interface from the request, but then drops the RCU read lock and continues to use both sdata and the embedded wpan_dev. mac802154_stop_beacons_locked() cancels only pending beacon work, clears local->beacon_req and frees the request. A beacon worker that is already running can therefore continue after interface teardown and dereference the freed netdev private area. The scan worker already pins the netdev before leaving RCU. Apply the same lifetime rule to the beacon worker: take a netdev reference while the request is still protected by RCU, and release it on all paths that continue after the reference is acquired.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80731", "url": "https://ubuntu.com/security/CVE-2026-80731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header dev_validate_header() reads dev->hard_header_len directly when zero-padding short link layer headers for CAP_SYS_RAWIO holders: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Packet send paths call dev_validate_header() on skbs whose headroom was allocated from an earlier hard_header_len read. If the device is reconfigured so that dev->hard_header_len increases before validation, the memset writes past the reserved buffer, an out-of-bounds write. This out-of-bounds write is masked in some SOCK_RAW paths today because the same concurrent increase can first make skb_push() exceed the reserved headroom and trigger skb_under_panic(). Remove the zero-padding branch before making those hard_header_len reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite. This path is only reached for variable length L2 protocols, where len < hard_header_len but len >= min_header_len. No remaining in-tree variable length L2 protocol implements header_ops->validate, and the CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input. Drop the CAP_SYS_RAWIO branch. The remaining reads of dev->hard_header_len in dev_validate_header() are comparisons only and have no memory safety impact.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74663", "url": "https://ubuntu.com/security/CVE-2026-74663", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: reject overly deep qdisc hierarchies Deep qdisc hierarchies can lead to excessive recursion in qdisc tree walkers and exhaust the kernel stack. The existing loop check does not cover the create-and-graft path, so a hierarchy can still be extended by creating a new child qdisc below an already deep parent. Store the hierarchy depth in struct Qdisc and update it when qdiscs are grafted. Reject new child qdiscs once the parent is already at the maximum allowed depth.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74664", "url": "https://ubuntu.com/security/CVE-2026-74664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74666", "url": "https://ubuntu.com/security/CVE-2026-74666", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: synchronize pressure clearing with ring reconfiguration packet_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. Move the existing receive hook assignment into the same sk_receive_queue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix. Serialize packet_recvmsg() pressure clearing with the same queue lock only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear and the socket has moved away from tpacket_rcv, packet_set_ring() has already detached the socket and waited for synchronize_net(), so no new packet input can set the flag again. packet_poll() already holds sk_receive_queue.lock, so it uses the new unlocked helper directly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74667", "url": "https://ubuntu.com/security/CVE-2026-74667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: reset the MAC header on the packet-socket transmit path packet_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here. For frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c (\"macsec: do not read an unset MAC header in macsec_encrypt()\"). packet_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too. Found by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74668", "url": "https://ubuntu.com/security/CVE-2026-74668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in TX_RING send path tpacket_snd() reads dev->hard_header_len independently for skb allocation and header construction in tpacket_fill_skb(). Concurrent netdevice reconfiguration can therefore make the reserved headroom smaller than the amount later pushed, or make copylen - hard_header_len negative. Snapshot hard_header_len once before processing ring frames and use it for the frame limit, headroom allocation, copy length, and skb construction. Pass the snapshot to tpacket_fill_skb(). The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74582", "url": "https://ubuntu.com/security/CVE-2026-74582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74669", "url": "https://ubuntu.com/security/CVE-2026-74669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write. Clear the stale option metadata after resetting the network header. Keep the remaining control block fields, including the ingress interface used by the ICMP response path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74670", "url": "https://ubuntu.com/security/CVE-2026-74670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74671", "url": "https://ubuntu.com/security/CVE-2026-74671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix out-of-bounds read in xattr_verify() The digest-length check in xattr_verify() mixes int and size_t: \tif (xattr_len - sizeof(xattr_value->type) - hash_start >= \t\t\tiint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns \"1 - 1 - 1\" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74673", "url": "https://ubuntu.com/security/CVE-2026-74673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74675", "url": "https://ubuntu.com/security/CVE-2026-74675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: stabilize tty reference in kbd_keycode with tty_port_tty_get kbd_keycode() reads vc->port.tty without acquiring a tty reference, racing against con_shutdown() which clears port.tty under a different lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference for the duration the tty pointer is needed.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74676", "url": "https://ubuntu.com/security/CVE-2026-74676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74678", "url": "https://ubuntu.com/security/CVE-2026-74678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup() When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb. usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the \"drop\" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure). Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74679", "url": "https://ubuntu.com/security/CVE-2026-74679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Use unsigned int for ndp_index The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74680", "url": "https://ubuntu.com/security/CVE-2026-74680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74682", "url": "https://ubuntu.com/security/CVE-2026-74682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: \tu->packets = urb_packs; \tu->buffer_size = maxsize * u->packets; \tif (fmt->fmt_type == UAC_FORMAT_TYPE_II) \t\tu->packets++; /* for transfer delimiter */ \tu->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: \toffs = 0; \tfor (i = 0; i < urb_ctx->packets; i++) { \t\turb->iso_frame_desc[i].offset = offs; \t\turb->iso_frame_desc[i].length = ep->curpacksize; \t\toffs += ep->curpacksize; \t} \turb->transfer_buffer_length = offs; \turb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74683", "url": "https://ubuntu.com/security/CVE-2026-74683", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74688", "url": "https://ubuntu.com/security/CVE-2026-74688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: clear control chunk transport if it is being removed sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74689", "url": "https://ubuntu.com/security/CVE-2026-74689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/atm: fix slab-out-of-bounds read in vcc_setsockopt() vcc_setsockopt() contained an ineffective optlen check: if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname)) return -EINVAL; If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller passed a mismatched level), the length check optlen != __SO_SIZE(optname) was short-circuited and bypassed. Execution then fell through to switch(optname), calling copy_from_sockptr() assuming optval contained sufficient space. Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(), this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the expected structure size. Fix this by using copy_safe_from_sockptr(), which unconditionally validates that optlen is at least the expected size before copying. Also change the local 'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches its sizeof(int) ABI encoding on 64-bit systems.", "cve_priority": "low", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80732", "url": "https://ubuntu.com/security/CVE-2026-80732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: pata_sl82c105: fix bridge revision use-after-free pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b (\"PCI: Change all drivers to use pci_device->revision\") replaced a configuration-space read with direct access to the cached revision field, but left that access after pci_dev_put(). The bridge may therefore be freed before its revision is read. Read the revision before dropping the reference.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74691", "url": "https://ubuntu.com/security/CVE-2026-74691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 (\"net: thunderbolt: Enable DMA paths only after rings are enabled\") moved the path enable to the end of tbnet_connected_work() and documented why: \t/* Both logins successful so enable the rings, high-speed DMA \t * paths and start the network device queue. \t * \t * Note we enable the DMA paths last to make sure we have primed \t * the Rx ring before any incoming packets are allowed to \t * arrive. \t */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional \"return 0\". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74692", "url": "https://ubuntu.com/security/CVE-2026-74692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80733", "url": "https://ubuntu.com/security/CVE-2026-80733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: remove WARN_ON_ONCE() from sk_mc_loop() sk_mc_loop() can be called for sockets that are neither AF_INET nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet socket over virtual devices such as VRF or ipvlan). In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls through the switch statement and triggers WARN_ON_ONCE(1). Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP options, so loopback should default to true without generating a warning.", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74693", "url": "https://ubuntu.com/security/CVE-2026-74693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74694", "url": "https://ubuntu.com/security/CVE-2026-74694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74696", "url": "https://ubuntu.com/security/CVE-2026-74696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74697", "url": "https://ubuntu.com/security/CVE-2026-74697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Disable EOP for TPA on all chips to prevent data corruption EOP (End of frame padding) on the AGG ring may cause overlapping of zero padding at the end of one segment with the next segment's data. If Relaxed Ordering (RO) is enabled, the zero padding may overwrite valid data in the next segment and corrupt the data. Older chips (P5 and older) do not automatically disable RO when EOP is enabled. On some ARM systems, data corruption was reported on 57508 (P5) chips with RO enabled. Always disable EOP on all chips on the AGG rings when TPA is enabled to fix the data corruption.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74700", "url": "https://ubuntu.com/security/CVE-2026-74700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race. Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio: 1. Both threads enter tc_new_tfilter, both find the chain empty, both drop filter_chain_lock 2. u32 finishes tcf_proto_create(\"u32\") first, calls tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create(\"flower\") later, calls tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp already there, takes a reference on it, destroys flower's own tp_new and returns u32_tp to the caller. Flower then hits the kind mismatch check (because it requested for kind \"flower\" but tp->ops->kind is \"u32\") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero. At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC): [ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524 Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378) Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378) Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459) Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held. To explain why I used a temp variable \"not_lockless\" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter. A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74701", "url": "https://ubuntu.com/security/CVE-2026-74701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/openvswitch: check Ethernet header length in key_extract() When a packet arrives on an ARPHRD_NONE device (e.g. TUN), ovs_flow_key_extract() trusts the user-provided skb->protocol field: if it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes for MAC addresses and parse_ethertype() pulls 2 more, either of which triggers a kernel BUG in __skb_pull() when the linear area is too small. kernel BUG at include/linux/skbuff.h:2848! RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933 ovs_flow_key_extract+0x419/0xa70 ovs_vport_receive+0x222/0x390 netdev_frame_hook+0x3e0/0x630 tun_get_user+0x2d0c/0x38e0 Fixed by calling check_header() in key_extract() before accessing the Ethernet header.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74704", "url": "https://ubuntu.com/security/CVE-2026-74704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter The sch_cake ACK filter parses packets to find the TCP header and filter duplicated ACKs if the flow is backlogged. The parsing code contains a WARN_ON(1) which can be triggered by a malformed IP header in certain cases. Depending on the system configuration, this leads either to either spamming dmesg with warnings, or a panic if panic_on_warn is set. The code already correctly skips the offending packet in the branch that triggers the warning, so the WARN_ON itself doesn't really serve any purpose. So just drop it altogether to avoid the inconvenient side effects.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74705", "url": "https://ubuntu.com/security/CVE-2026-74705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74714", "url": "https://ubuntu.com/security/CVE-2026-74714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch() reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto the ehash chain, drops the bucket lock, and only afterwards sets rsk_refcnt to 3. Lockless readers such as __inet_lookup_established() handle this with refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain sock_hold() while holding the bucket lock, on the assumption that the lock guarantees sk_refcnt > 0. That assumption does not hold for request_sock: CPU 0 CPU 1 ----- ----- tcp_conn_request() reqsk_queue_hash_req() inet_ehash_insert(req) spin_lock(bucket) __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0 spin_unlock(bucket) bpf_iter_tcp_established_batch() spin_lock(bucket) sock_hold(req) <-- addition on 0 spin_unlock(bucket) refcount_set(&req->rsk_refcnt, 3) // clobbers saturated value which surfaces as: refcount_t: addition on 0; use-after-free. WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1 Call Trace: bpf_iter_tcp_established_batch+0x14e/0x170 bpf_iter_tcp_batch+0x53/0x200 bpf_iter_tcp_seq_next+0x27/0x70 bpf_seq_read+0x107/0x410 vfs_read+0xb9/0x380 The iterator's stolen reference is lost when the publishing CPU's refcount_set() overwrites the count, leaving the socket one reference short. When the last legitimate owner drops its reference the reqsk is freed while still reachable, leading to use-after-free. This reproduces in seconds with tcp_syncookies=0, a handful of threads doing connect()/close() to a local listener while others read an iter/tcp link in a tight loop. Use refcount_inc_not_zero() and skip the socket on failure. A skipped socket is still part of the bucket, so keep counting it in expected. The reallocations are sized from expected, and a request sock whose refcount gets published while the lock is held across the last realloc must already have room. A skipped socket is counted in expected but never batched, so end_sk can be short of expected on a batch that is actually complete. Decide completeness by whether the walk left any socket behind instead. The WARN after the locked realloc checks the same, replacing an end_sk == expected check that could not hold on that path since commit cdec67a489d4 (\"bpf: tcp: Make sure iter->batch always contains a full bucket snapshot\"). If every matching socket in a bucket is mid-init (refcount 0), end_sk stays 0. Advance to the next bucket rather than returning a batch entry that was never filled this round.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74717", "url": "https://ubuntu.com/security/CVE-2026-74717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fw_tracer, return NULL on create error Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below. Switch tracer creation to return NULL on failure only, so callers only need a single NULL check. Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core] pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core] sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P) mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core] devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core] process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74718", "url": "https://ubuntu.com/security/CVE-2026-74718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: fix net namespace reference leak in reload devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net with a held reference. When the requested namespace differs from the current one and the reload action is not DRIVER_REINIT, the function returns -EOPNOTSUPP without releasing the reference. Add the missing put_net() on this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74583", "url": "https://ubuntu.com/security/CVE-2026-74583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_route: fix fastmap use-after-free on filter The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter. This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths. Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16:00 UTC" }, { "cve": "CVE-2026-74719", "url": "https://ubuntu.com/security/CVE-2026-74719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74720", "url": "https://ubuntu.com/security/CVE-2026-74720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve pointer state for commuted arithmetic When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74722", "url": "https://ubuntu.com/security/CVE-2026-74722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm \"syz.0.17\", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74724", "url": "https://ubuntu.com/security/CVE-2026-74724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: avoid out-of-bounds write in ip_vs_nat_icmp Sashiko warns that local attacker can modify the packet while it is processed by IPVS. Some places read the IP ihl field multiple times which can cause out-of-bounds access. One such place is ip_vs_nat_icmp where we can write after the validated area. Fix it by providing ciph argument just like it is done for IPv6 and use ciph->len as offset to the embedded transport header. Modify some IPv4 header checks by reading the ihl field only once.", "cve_priority": "high", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80739", "url": "https://ubuntu.com/security/CVE-2026-80739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2026-09-03 13:06:00 UTC" }, { "cve": "CVE-2026-74726", "url": "https://ubuntu.com/security/CVE-2026-74726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) 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) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-74730", "url": "https://ubuntu.com/security/CVE-2026-74730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Pin the 'struct nfs_server' during a FREE_STATEID call Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.", "cve_priority": "medium", "cve_public_date": "2026-08-22 16:16:00 UTC" }, { "cve": "CVE-2026-80708", "url": "https://ubuntu.com/security/CVE-2026-80708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-68253", "url": "https://ubuntu.com/security/CVE-2026-68253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68169", "url": "https://ubuntu.com/security/CVE-2026-68169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a \"not found\" sentinel.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64586", "url": "https://ubuntu.com/security/CVE-2026-64586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: drain bus_reset work on device removal brcmf_fw_crashed() and the debugfs \"reset\" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs \"reset\" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. 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-68198", "url": "https://ubuntu.com/security/CVE-2026-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix use-after-free in aggr_reset_state() The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68254", "url": "https://ubuntu.com/security/CVE-2026-68254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74441", "url": "https://ubuntu.com/security/CVE-2026-74441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port().", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68367", "url": "https://ubuntu.com/security/CVE-2026-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20: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-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-80893", "url": "https://ubuntu.com/security/CVE-2026-80893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork() copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages. No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows: offset before=120e00 offset after =120e02 The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it. Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte(). A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80700", "url": "https://ubuntu.com/security/CVE-2026-80700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate external BO copy bounds for both stride paths vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80887", "url": "https://ubuntu.com/security/CVE-2026-80887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: use check_add_overflow for shader size+offset bound vmw_shader_define() validates the user-supplied shader window against its backing buffer with \t(u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18: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-80888", "url": "https://ubuntu.com/security/CVE-2026-80888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: drop dma_buf reference on foreign-fd prime import ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74445", "url": "https://ubuntu.com/security/CVE-2026-74445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80702", "url": "https://ubuntu.com/security/CVE-2026-80702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74446", "url": "https://ubuntu.com/security/CVE-2026-74446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: hold event_mutex while checkpointing CRIU events kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74448", "url": "https://ubuntu.com/security/CVE-2026-74448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix QID bit leak in pqm_create_queue() When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f)", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80703", "url": "https://ubuntu.com/security/CVE-2026-80703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5)", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-74454", "url": "https://ubuntu.com/security/CVE-2026-74454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO.", "cve_priority": "high", "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-80706", "url": "https://ubuntu.com/security/CVE-2026-80706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: softing: fw_parse(): validate firmware record spans fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80707", "url": "https://ubuntu.com/security/CVE-2026-80707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. [mkl: add Message-ID]", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-80678", "url": "https://ubuntu.com/security/CVE-2026-80678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Fix slave registration race and error handling In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80709", "url": "https://ubuntu.com/security/CVE-2026-80709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80710", "url": "https://ubuntu.com/security/CVE-2026-80710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix undersized format-check buffer fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80679", "url": "https://ubuntu.com/security/CVE-2026-80679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential NULL pointer dereference dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80680", "url": "https://ubuntu.com/security/CVE-2026-80680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error.", "cve_priority": "low", "cve_public_date": "2026-08-28 08:16: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-80890", "url": "https://ubuntu.com/security/CVE-2026-80890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: reject stale cookies with mismatched verification tags sctp_unpack_cookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4. For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent. The broad check lets an expired Action A restart cookie reach sctp_sf_do_dupcook_a(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association. Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74470", "url": "https://ubuntu.com/security/CVE-2026-74470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: \trep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - \t\t\t RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); \tarr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.", "cve_priority": "high", "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-74472", "url": "https://ubuntu.com/security/CVE-2026-74472", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the \"->state != UBLK_S_DEV_DEAD\" test that ublk_stop_dev_unlocked() uses as its proxy for \"a disk is attached\", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state.", "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-80681", "url": "https://ubuntu.com/security/CVE-2026-80681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: re-fetch eth header after route_shortcircuit() Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74581", "url": "https://ubuntu.com/security/CVE-2026-74581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: clear suppressed fib6 rule result fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one.", "cve_priority": "medium", "cve_public_date": "2026-08-21 17:16: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-80714", "url": "https://ubuntu.com/security/CVE-2026-80714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: do not propagate one-packet flag to synced conns Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74501", "url": "https://ubuntu.com/security/CVE-2026-74501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix use-after-free in ump_to_endpoint() create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74502", "url": "https://ubuntu.com/security/CVE-2026-74502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: fix double free of out_cvts on rawmidi error snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80716", "url": "https://ubuntu.com/security/CVE-2026-80716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16: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-74510", "url": "https://ubuntu.com/security/CVE-2026-74510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.", "cve_priority": "high", "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-80717", "url": "https://ubuntu.com/security/CVE-2026-80717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate Adaptation Indication parameter length The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80891", "url": "https://ubuntu.com/security/CVE-2026-80891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Validate AIBV and AISB before pinning guest pages The AIBV holds one bit per MSI-X vector for a given function. The size of the bit vector is derived from the NOI and the AIBVO. If the size of the AIBV exceeds a single page boundary, then reject the request as we cannot safely pin the guest AIBV. Similarly reject the request if the AISB address is not 8-byte aligned as the architecture requires doubleword alignment for the summary bit address. Since the AISBO can address up to 64 bits, the size of the AISB can only be 8 bytes for the function. This also ensures the AISB doesn't exceed a single page boundary.", "cve_priority": "high", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-80684", "url": "https://ubuntu.com/security/CVE-2026-80684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix NULL dereference on AIBV allocation failure The airq_iv_create() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvm_zpci_set_airq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure.", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74515", "url": "https://ubuntu.com/security/CVE-2026-74515", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Reject adapter interrupt forwarding if already enabled The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74516", "url": "https://ubuntu.com/security/CVE-2026-74516", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a \"safe\" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "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-80718", "url": "https://ubuntu.com/security/CVE-2026-80718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 (\"percpu: make percpu-km set chunk->populated bitmap properly\") introduced the bitmap overflow issue. Later, commit b539b87fed37f (\"percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated\") added pcpu_nr_empty_pop_pages and caused the accounting issue.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-80892", "url": "https://ubuntu.com/security/CVE-2026-80892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: cap LZMA stream pool size fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream pool from num_possible_cpus() when the lzma_streams module parameter is unset, then z_erofs_load_lzma_config() preallocates one image-supplied dictionary per stream, accepting dictionaries up to 8 MiB. On high-CPU systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed decoder state until the erofs module is unloaded. Impact: An EROFS image mounted by the system can pin up to 8 MiB of vmalloc memory per LZMA stream, either as intended or unexpectedly. Bound the default stream count by a new CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the worst-case default preallocation is 128 MiB if the number of CPUs is no less than 16 while preserving the existing per-image dictionary limit. An explicit lzma_streams module parameter is still honoured as-is, so administrators who deliberately size the pool are not affected.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18: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-74522", "url": "https://ubuntu.com/security/CVE-2026-74522", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __close_file_table_ids() A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17: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-80691", "url": "https://ubuntu.com/security/CVE-2026-80691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE In the iblock_execute_pr_out() function, PRO_PREEMPT, PRO_PREEMPT_AND_ABORT, and PRO_RELEASE all perform callback capability checks through ops->pr_clear. The error check allows unimplemented hooks to pass through the gate, resulting dereferencing a NULL function pointer. Check whether the hooks that need to be called are supported.", "cve_priority": "high", "cve_public_date": "2026-08-28 08:16:00 UTC" }, { "cve": "CVE-2026-74531", "url": "https://ubuntu.com/security/CVE-2026-74531", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: hold conn reference in abort_conn_sync() There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74532", "url": "https://ubuntu.com/security/CVE-2026-74532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Validate length before parsing diagnostics TLV btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access.", "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-74541", "url": "https://ubuntu.com/security/CVE-2026-74541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: clear iso_data always when detaching conn from hcon When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-80722", "url": "https://ubuntu.com/security/CVE-2026-80722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate individual TWT params before driver setup ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. [edit commit message to not overclaim lack of validation nor understate driver impact]", "cve_priority": "medium", "cve_public_date": "2026-08-28 08:16: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-74550", "url": "https://ubuntu.com/security/CVE-2026-74550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74551", "url": "https://ubuntu.com/security/CVE-2026-74551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) DMA-align output buffer Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74552", "url": "https://ubuntu.com/security/CVE-2026-74552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74553", "url": "https://ubuntu.com/security/CVE-2026-74553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74555", "url": "https://ubuntu.com/security/CVE-2026-74555", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 (\"scsi: libsas: Don't always drain event workqueue for HA resume\") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path.", "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-80901", "url": "https://ubuntu.com/security/CVE-2026-80901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix the checksum validations ip_vs_in_icmp_v6() is missing checksum validation for ICMPv6 packets from clients. In fact, as for TCP/UDP we should validate the checksum for ICMP packets only when we mangle the packets on MASQ or on reply for tunnel. Also, Sashiko points out that handle_response_icmp() being common for IPv4 and IPv6 is missing the pseudo-header calculation while validating ICMPv6 messages from real servers which is a problem if checksum is not validated by the hardware. Fix the problems by creating ip_vs_checksum_common_check() helper and use it for TCP/UDP/ICMP both for IPv4 and IPv6. Rely on the nf_checksum() for validating the ICMP messages but use it also for TCP and UDP. Use correct IP offset for IP_VS_DBG_RL_PKT for TCP/UDP/SCTP. IPVS packets (TCP/UDP/SCTP/ICMP) do not need checksum validation on LOCAL_OUT (local clients or local real servers) and on FORWARD (traffic from servers on LAN). Do it only on LOCAL_IN, in case nf_checksum() is not called on PRE_ROUTING. Also, ip_vs_checksum_complete() can be marked static.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17: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-74572", "url": "https://ubuntu.com/security/CVE-2026-74572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74574", "url": "https://ubuntu.com/security/CVE-2026-74574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-80902", "url": "https://ubuntu.com/security/CVE-2026-80902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA When terminating DMA transfers, active descriptors are not properly reclaimed. Only cyclic descriptors were handled, leaving non-cyclic descriptors and their LLI chains to be permanently leaked. Fix by using vchan_terminate_vdesc() which handles both cyclic and non-cyclic descriptors by adding them to desc_terminated queue for proper cleanup. Add pchan->desc != pchan->done check to prevent double-adding completed descriptors, which would corrupt the list.", "cve_priority": "medium", "cve_public_date": "2026-09-04 18:17:00 UTC" }, { "cve": "CVE-2026-74575", "url": "https://ubuntu.com/security/CVE-2026-74575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Prevent XDomain delayed work use-after-free on disconnect tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 (\"thunderbolt: Run tb_xdp_handle_request() in system workqueue\") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18: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-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" } ], "log": [ "", " * noble/linux: 6.8.0-148.148 -proposed tracker (LP: #2170052)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.10.12)", "", " * Upstream stable patch causes build failure when CONFIG_XFRM_MIGRATE is", " enabled (LP: #2169329)", " - SAUCE: Revert \"xfrm: fix NAT-related field inheritance in SA migration\"", "", " * Loading certificate with --import enrolls it into the platform keyring", " instead of the machine keyring (LP: #2131181)", " - SAUCE: integrity: Load MokListRT certs into the machine keyring", "", " * CVE-2026-74350", " - ocfs2: validate fast symlink target during inode read", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853)", " - drm/gem: Consider GEM object reclaimable if shrinking fails", " - bus: fsl-mc: wait for the MC firmware to complete its boot", " - drm/amd/display: Fix DPMS using partially updated pipe context", " - drm/panel: jadard-jd9365da-h3: set prepare_prev_first", " - drm/amd/pm: Check SMUv13.0.6/12 metrics integrity", " - ALSA: usb-audio: Propagate write errors in generic mixer put callbacks", " - ima: return error early if file xattr cannot be changed", " - usb: gadget: udc: skip pullup() if already connected", " - tee: optee: Allow MT_NORMAL_TAGGED shared memory", " - tools/nolibc: avoid call to wcslen() in _start_c() inserted by clang", " - PCI: Stop setting cached power state to 'unknown' on unbind", " - hfsplus: fix issue of direct writes beyond end-of-file", " - wifi: mac80211: always allow transmitting null-data on TXQs", " - kcsan: Silence -Wmaybe-uninitialized when calling __kcsan_check_access()", " - firmware: stratix10-svc: change get provision data to async SMC call", " - bridge: Do not suppress ARP probes and DAD NS unconditionally", " - soundwire: validate DT compatible before parsing it", " - media: rc: mceusb: Add support for 04eb:e033", " - thunderbolt: Keep the domain reference while processing hotplug", " - thunderbolt: Don't create multiple DMA tunnels on firmware connection", " manager", " - net: dsa: mv88e6xxx: fix number of g1 interrupts for 6320 family", " - PCI: switchtec: Add Gen6 Device IDs", " - net: dsa: mv88e6xxx: define .pot_clear() for 6321", " - net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family", " - media: em28xx-video: fix missing res_free() on init_usb_xfer failure", " - crypto: omap - add omap_des_unregister_algs helper", " - clk: renesas: cpg-mssr: Add number of clock cells check", " - drm/bridge: tc358768: Set pre_enable_prev_first for reverse order", " - ASoC: ti: omap3pandora: update board check to use DT compatible", " - mmc: core: Add validation for host-provided max_segs", " - drm/amd/display: Fix CRC open failure during active rendering", " - PCI: intel-gw: Enable clock before PHY init", " - hfsplus: rework hfsplus_readdir() logic", " - net: phy: motorcomm: use device properties for firmware tuning", " - drm/gud: Add RCade Display Adapter VID/PID pair", " - media: video-i2c: use vb2_video_unregister_device on driver removal", " - net: dsa: realtek: rtl8365mb: add support for RTL8367SB", " - integrity: Check for NULL returned by asymmetric_key_public_key", " - drivers/of: validate status properties in reconfig state changes", " - soundwire: intel: Move suspend tracking from trigger to pm suspend", " - clk: samsung: exynos850: mark APM I3C clocks as critical", " - scsi: pm8001: Reject firmware update in fatal error state", " - scsi: pm8001: Reject non-fatal dump when controller is crashed", " - crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y", " - crypto: atmel-ecc - add support for atecc608b", " - media: imon: Add iMON VFD HID OEM v1.2 key mappings", " - RDMA/mlx5: Use QP port when decoding responder CQEs", " - mailbox: Make mbox_send_message() return error code when tx fails", " - PCI: Wait for device readiness after D3hot -> D0uninitialized transition", " - ALSA: usx2y: Drain pending US-428 pipe-4 output commands", " - sched/fair: Reject misfit pulls onto busy SMT siblings on asym-capacity", " - 9p: invalidate readdir buffer on seek", " - arm64/daifflags: Make local_daif_*() helpers __always_inline", " - 9p: use kvzalloc for readdir buffer", " - bridge: Add missing READ_ONCE() annotations around FDB destination port", " - thunderbolt: Don't access path config space on Lane 1 adapters in", " tb_switch_reset_host()", " - thunderbolt: Improve multi-display DisplayPort tunnel allocation", " - firmware: arm_scmi: Validate SENSOR_UPDATE payload size", " - firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size", " - thunderbolt: Increase timeout for Configuration Ready bit", " - thunderbolt: Verify Router Ready bit is set after router enumeration", " - bitfield: wire __bf_shf to __builtin_ctzll", " - nvme-core: align fabrics_q teardown with admin_q in nvme_free_ctrl", " - net: usb: qmi_wwan: add MeiG SRM813Q", " - net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()", " - net/sched: sch_drr: make cl->quantum lockless", " - befs: handle set_blocksize failures", " - ntfs3: handle set_blocksize failures", " - minix: handle set_blocksize failures", " - isofs: handle set_blocksize failures", " - USB: cdc-acm: start bulk-IN polling when ALWAYS_POLL_CTRL is set", " - usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue", " - usb: host: add ARCH_AIROHA in XHCI MTK dependency", " - char/nvram: Remove redundant nvram_mutex", " - rcu-tasks: Fix possible boot-time tests failed for the call_rcu_tasks()", " - wifi: rtw89: pci: enable LTR based on pcie control register", " - netlabel: fix IPv6 unlabeled address add error handling", " - rds: annotate data-race around rs_seen_congestion", " - s390/zcore: Removed unused variables", " - clk: socfpga: agilex: implement l3_main_free_clk", " - drm/panel: simple: Add AM-1280800W8TZQW-T00H", " - mips: cps: Assemble jr.hb with an R2 ISA level", " - iio: adc: qcom-spmi-iadc: balance enable_irq_wake() on driver unbind", " - irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed", " - ALSA: usb-audio: Add quirk for Novation Mininova", " - net: hsr: require valid EOT supervision TLV", " - net: thunderx: fix PTP device ref leak in nicvf_probe()", " - drm/amd/pm/si: Fix updating clock limits from power states", " - ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()", " - hfs: rework hfsplus_readdir() logic", " - pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP", " - host1x: bus: Fix missing ops null check in error teardown", " - scripts: modpost: detect and report truncated buf_printf() output", " - drm/nouveau/gsp: add SEC2 to GA100 chip table", " - ASoC: Intel: catpt: Complete coredump handling", " - libbpf: Add __NR_bpf definition for LoongArch", " - soundwire: dmi-quirks: Disable ghost Realtek devices", " - gfs2: page poisoning fix", " - soundwire: only handle alert events when the peripheral is attached", " - mmc: davinci: fix mmc_add_host order in probe", " - mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC", " - tracing: Disable KCOV instrumentation for trace_irqsoff.o", " - mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC", " - iio: light: stk3310: Deal with the ps interrupt issue in PM", " - iio: accel: mma8452: switch to non-devm request_threaded_irq()", " - libbpf: Also reset {insn,data}_cur on realloc failure", " - net: ibm: emac: Reserve VLAN header in MJS limit", " - ASoC: qcom: q6apm: return error code to consumers on failures", " - ASoC: codecs: pcm3168a: Drop CONFIG_PM-conditional preproc directive", " - ACPI: PCI: Clear _DEP dependencies after PCI root bridge attach", " - net: wwan: t7xx: Add delay between MD and SAP suspend", " - iommu/rockchip: disable fetch dte time limit", " - ASoC: codecs: rk3328: Use managed GPIO and clock helpers", " - ALSA: seq: oss: Reject reads that cannot fit the next event", " - dpaa2-switch: fix the error path in dpaa2_switch_rx()", " - thermal/drivers/qcom/tsens: Atomic temperature read with hardware-guided", " retries", " - RDMA/irdma: Fix typo in SQ completions generation", " - net/mlx5: E-Switch, align disable sequence with switchdev-to-legacy", " transition", " - clk: keystone: don't cache clock rate", " - ALSA: hda/realtek: Add quirk for ASUS VivoBook X509DAP", " - ipmi: si: Use platform_get_irq_optional() to retrieve interrupt", " - drm/amdkfd: Unwind debug trap enable on copy_to_user failure", " - wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer", " notifications", " - RDMA/mlx5: Fix state and counter desync on loopback enable failure", " - net: cpsw_new: unregister devlink on port registration failure", " - net: microchip: sparx5: clean up PSFP resources on flower setup failure", " - NFS: fix eof updates after NFSv4.2 fallocate/zero-range", " - xprtrdma: Add request-pool slack for delayed recycling", " - configfs_depend_prep(): pass configfs_dirent instead of dentry", " - tls: Flush backlog before waiting for a new record", " - platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk", " table", " - wifi: mt76: transform aspm_conf for pci_disable_link_state", " - btrfs: protect sb_write_pointer() with invalidate lock", " - hwmon: (adt7462) Add of_match_table to support devicetree", " - net: dsa: qca8k: Add support for force mode for fixed link topology", " - vdpa/ifcvf: handle dev_set_name() failure in ifcvf_vdpa_dev_add()", " - ALSA: hda/realtek: Add quirk for HP 255 15.6 inch G9 Notebook PC", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IRH8", " - ata: libata-pmp: add JMicron JMS562 quirk", " - platform/x86: intel-hid: Add HP ProBook x360 440 G1 to", " button_array_table", " - sctp: Unwind address notifier registration on failure", " - PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi, SDX62/SDX65 modems", " - dmaengine: dw-axi-dmac: fix PM for system sleep and channel alloc", " - hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i", " - spi: xilinx: let transfers timeout in case of no IRQ", " - Bluetooth: btusb: Add Mercusys MA530 for Realtek RTL8761BUV", " - Bluetooth: btusb: Add support for TP-Link TL-UB250", " - ASoC: rockchip: rockchip_pdm: Reorder clock enable sequence", " - ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure", " - Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV", " - sparc64: uprobes: add missing break", " - ptp: ocp: add shutdown callback", " - vsock: use sk_acceptq_is_full() helper in all transports", " - e1000e: limit endianness conversion to boundary words", " - net/sched: act_csum: don't mangle UDP tunnel GSO packets", " - i3c: mipi-i3c-hci: Tolerate i3c_master_add_i3c_dev_locked() failures in", " DAA", " - sparc: Disable compat support with LLD", " - ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT", " - fuse: set ff->flock only on success", " - scsi: bfa: Reduce kernel stack usage in", " bfa_fcs_lport_fdmi_build_portattr_block()", " - gpio: pisosr: Read \"ngpios\" as u32", " - ALSA: usb-audio: Add quirk flags for SC13A", " - ALSA: hda/conexant: Add pin config quirk for Lenovo IdeaPad Slim 5", " 16AKP10", " - leds: uleds: Return -EFAULT on copy_to_user() failure", " - leds: pca9532: Don't stop blinking for non-zero brightness", " - mfd: tps65219: Make poweroff handler conditional on system-power-", " controller", " - mfd: rsmu: Add 8a34002 support", " - drm/amdkfd: check find_first_zero_bit before __set_bit on", " kfd->doorbell_bitmap", " - drm/amdgpu: Use system unbound workqueue for soft IH ring", " - ALSA: usb-audio: Add quirk for YAMAHA CDS3000", " - md/raid5: account discard IO", " - md/raid5: let stripe batch bm_seq comparison wrap-safe", " - rtc: aspeed: add AST2700 compatible", " - ksmbd: fix lease break and ack state handling", " - ksmbd: validate SMB2 lease create contexts", " - ksmbd: align SMB2 oplock break ack handling", " - ksmbd: use connection ClientGUID for lease lookup", " - ksmbd: treat unnamed DATA stream as base file", " - ksmbd: apply create security descriptor first", " - ksmbd: deny renaming directory with open children", " - ksmbd: start file id allocation at 1", " - ksmbd: break RH leases before delete-on-close", " - ksmbd: treat read-control opens as stat opens only for leases", " - PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()", " - PCI/sysfs: Use kstrtobool() to parse the ROM attribute input", " - regulator: da9121: Use subvariant ids in the I2C table", " - blk-cgroup: protect iterating blkgs with blkcg->lock in", " blkcg_print_stat()", " - rtc: bq32000: add delay between RTC reads", " - eth: mlx5: fix macsec dependency", " - fbdev: pm2fb: unwind WC setup on probe failure", " - drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend", " - netfilter: nf_conntrack_expect: zero at allocation time", " - drm/arm/komeda: fix error handling for clk_prepare_enable() and callers", " - ksmbd: fix n.data memory leak in ksmbd_vfs_set_dos_attrib_xattr", " - xen/front-pgdir-shbuf: free grant reference head on errors", " - freevxfs: don't BUG() on unknown typed-extent type", " - xen/gntalloc: validate grant count before allocation", " - ASoC: amd: yc: Add Alienware m15 R7 AMD to DMIC quirk table", " - ksmbd: fix credit charge calculation for SMB2 QUERY_INFO", " - wifi: ralink: RT2X00: init EEPROM properly", " - wifi: mac80211: validate deauth frame length before reason access", " - wifi: libertas: reject short monitor TX frames", " - ksmbd: find bound sessions during reauthentication", " - ksmbd: mark invalid session responses as signed", " - ksmbd: validate SID namespace before mapping IDs", " - gpio: dwapb: Mask interrupts at hardware initialization", " - netfilter: ipset: mark the rcu locked areas properly", " - smb/client: reduce fallocate zero buffer allocation", " - ALSA: hda/realtek: Fix speakers on MECHREVO WUJIE Series", " - btrfs: only account delalloc bytes for regular file inodes in", " btrfs_getattr()", " - spi: dw-dma: Wait for controller idle before completing Tx", " - wifi: iwlwifi: mvm: fix sched scan IE sizing", " - ALSA: hda/realtek: Add quirk for HP EliteBook 830 G8 (8AB8) to enable", " mute LEDs", " - arm64: fixmap: Allow 256K early_ioremap() at any offset", " - arm64: kprobes: Allow reentering kprobes while single-stepping", " - drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized", " - ALSA: hda/realtek: Add quirk for HP Pavilion x360", " - ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless", " - ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Samsung 750XBE/730XBE", " - wifi: mwifiex: replace one-element arrays with flexible array members", " - regulator: core: clamp voltage constraints before applying apply_uV", " - wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO", " - drm/gma500: return errors from Oaktrail HDMI I2C reads", " - phonet: check register_netdevice_notifier() error in", " phonet_device_init()", " - ALSA: usb-audio: Add dB map quirk for Razer Barracuda X 2.4", " - ALSA: hda/realtek: Add mute LED quirk for HP Laptop 14s-dr1xxx", " - ice: pass the return value of skb_checksum_help()", " - powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during", " crash", " - ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)", " - Drivers: hv: vmbus: add VTL2 redirect connection ID", " - ASoC: amd: yc: Add DMI quirk for HP Victus Laptop 16-e1xxx", " - hwmon: (corsair-psu) Fix linear11 calculation", " - spi: dw: fix wrong RX_SAMPLE_DLY setting after resume", " - ASoC: rt5645: Perform the initial jack detect at probe", " - ASoC: amd: yc: Add DMI quirk for HyperX OMEN Gaming Laptop 16-ap1xxx", " - firmware: stratix10-svc: fix FCS SMC call kernel-doc", " - ksmbd: remove stale channels from all sessions on teardown", " - wifi: mt76: mt7921: skip unknown CLC firmware records", " - of: dynamic: Fix overlayed devices not probing because of fw_devlink", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU\"", " - Revert \"Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU\"", " - ARM: 9484/1: enable interrupts when unhandled user faults are triggered", " - ARM: ensure interrupts are enabled in __do_user_fault()", " - EDAC/igen6: Fix interleave boundary condition", " - EDAC/igen6: Fix channel selection hash", " - EDAC/igen6: Fix channel address decode for non-hash mode", " - drm/virtio: Fix a NULL vs ERR_PTR() bug in", " virtio_gpu_user_framebuffer_create()", " - selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter", " - ufs: Convert ufs_get_page() to use a folio", " - ufs: Convert ufs_get_page() to ufs_get_folio()", " - ufs: do not treat unreadable directory blocks as empty", " - drm/cirrus: Use video aperture helpers", " - net: icmp: avoid invalid transport header access in icmp_send tracepoint", " - net/sched: act_api: budget all shared attributes in notify skbs", " - net/sched: act_api: size the RTM_GETACTION reply from the actions", " - net/sched: act_api: fix skb sizing and action leak on reoffload delete", " - smb/client: mark file sparse before emulating insert range", " - smb: client: transport: Fix debug printing in __release_mid()", " - raw: annotate disconnect-side IPv4 match writers", " - net: amd-xgbe: discard rx packets with bad FCS", " - OPP: of: Fix potential multiplication overflow when calculating freq", " - s390/checksum: call instrument_read() instead of kasan_check_read()", " - s390/checksum: provide and use cksm() inline assembly", " - s390/os_info: Introduce value entries", " - s390/ipl: Fix NULL deref in kdump without re-IPL parm block", " - s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block", " - workqueue: replace use of system_wq with system_percpu_wq", " - workqueue: reject watchdog thresholds that overflow jiffies", " - Bluetooth: btintel: Export few static functions", " - Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM", " - Bluetooth: hci_mrvl: Fix wrong return value check of", " wait_on_bit_timeout()", " - ASoC: ab8500: Reset the audio block before configuring it", " - ASoC: ab8500: Repair the DAPM capture graph", " - ASoC: ab8500: Correct digital interface format setup", " - ASoC: ab8500: Validate and program TDM slots correctly", " - ppp: ppp_async: simplify tty disc_data access", " - ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit", " - ALSA: hda/core: Use guard() for mutex locks", " - ALSA: hda: restore MFG widget enumeration after core split", " - s390/boot: Fix physical memory search range", " - ASoC: amd: renoir: fix disable_pdm_interrupts() to clear mask bits", " - perf/core: Skip empty AUX records with only format flags", " - locking/lockdep: Invalidate stale class_cache entries for zapped classes", " - ALSA: rawmidi: Expose the tied device number in info ioctl", " - ALSA: rawmidi: Show substream activity in info ioctl", " - ALSA: ump: Copy FB name string more safely", " - ALSA: ump: Copy safe string name to rawmidi", " - ALSA: ump: Update rawmidi name per EP name update", " - ASoC: ux500: Fix MSP stream lifecycle handling", " - ASoC: ux500: Propagate MSP setup errors", " - ASoC: ux500: Correct MSP frame and bit clock setup", " - ASoC: ux500: Validate MSP DAI configuration", " - mfd: db8500-prcmu: Remove needless return in three void APIs", " - arm: Handle KCOV __init vs inline mismatches", " - mfd: db8500-prcmu: Fold dbx500 header into db8500", " - ASoC: ux500: Request the MSP MMIO resource", " - ASoC: ux500: Program the MSP FIFO watermarks", " - btrfs: send: fix lost error return value in will_overwrite_ref()", " - net/rds: use clear_bit_unlock() in release_refill()", " - net/rds: tcp: don't force RDS_CONN_RESETTING over a concurrent shutdown", " - net: stmmac: reconfigure RX packet parser table in stmmac_hw_setup()", " after reset", " - selftests/alsa: Fix the step check for INTEGER controls", " - selftests/bpf: Update tests for new ct zone opts for nf_conntrack kfuncs", " - selftests/bpf: Fix flaky bpf_nf test when random NAT port is 0", " - bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()", " - octeontx2-af: mcs: Clear stale X2P calibration state before calibration", " - powerpc/kexec_file: Use inclusive range checks in add_usable_mem()", " - net/mlx5e: Fix setting RS FEC after remapping", " - net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%", " - net_sched: sch_fq_pie: implement lockless fq_pie_dump()", " - net/sched: pie: clamp psched_mtu in pie_drop_early", " - net: macb: rename bp->sgmii_phy field to bp->phy", " - ASoC: bcm: bcm63xx: Publish the OF module aliases", " - ASoC: Intel: SST: Publish the PCI module aliases", " - netfilter: ip6_tables: set F_PROTO when proto value is nonzero", " - ASoC: mt6351: Publish the OF module alias", " - virtio-pci: return IRQ_HANDLED after non-zero ISR", " - net: ipv6: Clamp to IP6_MAX_MTU in ip6_dst_mtu_maybe_forward", " - net: ethernet: cortina: Finish RX updates before NAPI completion", " - net: ethernet: cortina: No mapping is a dropped rx", " - net: ethernet: cortina: Count RX drops once per frame", " - net: ethernet: cortina: Count RX descriptors for freeq refill", " - drm/logicvc: Drop the select of the nonexistent", " CONFIG_DRM_KMS_DMA_HELPER", " - ALSA: hda: Introduce auto cleanup macros for PM", " - ALSA: hda/common: Use cleanup macros for PM controls", " - ALSA: hda/common: Use guard() for mutex locks", " - ALSA: hda: Report a change when only the channel status bytes move", " - watchdog: fix hrtimer start when pretimeout is zero", " - watchdog: msc313e: Enable clock before accessing hardware registers", " - watchdog: msc313e: Fix spurious reset on suspend", " - watchdog: msc313e: Fix undefined behavior", " - watchdog: msc313e: Sync timeout value if WDT was running at boot", " - net/micrel: Fix typos in micrel driver code comments", " - net: ks8851: Fix receiver error in 100BASE-TX mode following software", " power-down", " - hwmon: (gpio-fan) take fan_data->lock in gpio_fan_shutdown()", " - hwmon: (aspeed-pwm-tacho) Propagate reset deassert errors", " - selftests/powerpc/tm: Fix tcheck() reading uninitialised CR value", " - perf/core: Check sample_type in perf_sample_save_callchain", " - perf/x86/intel/ds: Clarify adaptive PEBS processing", " - perf/x86/intel/ds: Remove redundant assignments to sample.period", " - perf/x86/intel/ds: Factor out PEBS group processing code to functions", " - perf/x86/intel: Correct pt_regs->flags update for PEBS path", " - net/sched: cls_route: Reject handle aliasing", " - net/sched: cls_route: Fix in-place replace", " - net: sun4i-emac: fix missing of_node_put() for phy_node", " - octeontx2-af: fix PF/CGX debugfs PCI bus lookup", " - openvswitch: fix wrong flag value in get_ipv6_ext_hdrs()", " - powerpc/ps3: Fix repository.c build failure", " - crypto: x86/aria - add missing vzeroupper in AVX2 code", " - crypto: x86/aria - add missing vzeroupper in AVX-512 code", " - ALSA: ctxfi: Fix CA20K2 S/PDIF passthrough", " - dm/amdgpu: fix malformed link_settings debugfs output", " - watchdog: sunxi_wdt: preserve boot-enabled watchdog", " - tunnels: Drop stale dst when building an ICMP error for PMTUD", " - tracing: Let histogram values keep the percent and graph modifiers", " - exec: do_close_on_exec() before taking exec_update_lock", " - ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters()", " - net: hso: fix TIOCMIWAIT race", " - netfilter: report NLM_F_DUMP_FILTERED when all is filtered out", " - vdpa: solidrun: Free IRQs after request failure", " - scripts/sorttable: Mark long_size as __maybe_unused", " - KVM: PPC: Book3S HV: Set irqfd->producer only on success", " - s390/qeth: allow bridgeport queries despite OS_MISMATCH", " - hwmon: (applesmc) fix key backlight workqueue leak on register failure", " - hwmon: (pmbus) Clear generic status alarms with CLEAR_FAULTS", " - media: hevc: add bounded tile-count helpers", " - media: v4l2-h264: Fix memcmp() size in B1 reference list comparison", " - bnxt_en: Only restore LRO if the device supports TPA", " - mptcp: options: handle MPC data + csum reqd + no csum", " - mptcp: subflow: no need to copy thmac during ulp_clone", " - selftests: mptcp: fix an UAF in mptcp_connect.c", " - smb: client: fix file type corruption in cifs_reparse_point_to_fattr()", " - smb: client: fix file type corruption in wsl_to_fattr()", " - xfs: snapshot scrub stats when rendering them", " - xfs: snapshot old AGFL before rewriting it", " - xfs: signal inode btree xref error if get_rec returns an error", " - xfs: count escaped corruption errors in scrub stats", " - Revert \"arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries\"", " - Revert \"arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entries\"", " - Revert \"nvme-apple: Reset q->sq_tail during queue init\"", " - Revert \"nvme-apple: Prevent shared tags across queues on Apple A11\"", " - Revert \"nvme-apple: Drop the PRP null check chicken bit\"", " - Revert \"nvme: apple: Add Apple A11 support\"", " - Revert \"selftests/mm: skip COW tmpfile cases when fallocate() is", " unsupported\"", " - Revert \"selftests/mm: report unique test names for each cow test\"", " - Revert \"perf tests: Fix flakiness in BPF counters test on hybrid", " systems\"", " - perf evsel: Add per-thread warning for EOPNOTSUPP open failues", " - usb: usbtmc: don't store usb_device_id", " - usb: serial: spcp8x5: don't store usb_device_id", " - media: as102: do not rely on id table address comparison", " - netfilter: nft_set_pipapo_avx2: add missing vzeroupper", " - workqueue: Update documentation as per system_percpu_wq naming", " - Bluetooth: btintel: Fix compiler warning for multi_v7_defconfig config", " - Revert \"hwmon: (emc1403) Drop hysteresis for low limit temperature\"", " - Revert \"hwmon: (emc1403) Rely on subsystem locking\"", " - selftests/landlock: Add tests for access through disconnected paths", " - selftests/landlock: Add disconnected leafs and branch test suites", " - Revert \"alpha: don't leak hardware-fabricated FP exception bits to user", " space\"", " - Revert \"alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally\"", " - selftests/landlock: Add tests for whiteout object creation", " - sunvdc: fix -EIO issue due to lack of retries", " - media: video-i2c: fix buffer queue ordering", " - ipv6: Select best matching nexthop object in fib6_table_lookup()", " - ipv6: Honor oif when choosing nexthop for locally generated traffic", " - xfrm: avoid RCU warnings around the per-netns netlink socket", " - xfrm: fix compat ALLOCSPI request use-after-free", " - xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for", " xfrm_trans_reinject()", " - esp: downgrade zerocopy managed frags before mutating skb frags", " - ARM: socfpga: select the PL310 erratum 753970 workaround", " - RDMA/siw: Clear association under lock if siw_qp_modify fails in", " siw_accept", " - RDMA/rxe: validate access flags before swapping the MR's PD", " - RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access", " - firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS", " - clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate", " - RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds", " - net: convert dev->reg_state to u8", " - RDMA/core: Reject unregistering netdevs in ib_get_eth_speed", " - IB/iser: reject a remote invalidation of an unregistered direction", " - IB/isert: wait for deferred control PDU completions before releasing the", " connection", " - RDMA/mad: Fix receive buffer leak when PKey enforcement fails", " - RDMA/irdma: Enforce local fence for IB_WR_REG_MR", " - RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted", " - dmaengine: sprd: Fix runtime PM reference leak in probe", " - wifi: virt_wifi: free skb when disconnected", " - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path", " - wifi: libipw: reject too-short beacon and probe responses", " - wifi: libipw: reject too-short association responses", " - IB/IPoIB: Avoid restoring OPER_UP after multicast flush", " - wifi: cfg80211: check IP header size in cfg80211_classify8021d()", " - soundwire: cadence_master: wait and cancel cdns->work before clock stop", " - MIPS: Octeon: apply USB FDT fixups also when USB is modular", " - dma-coherent: Warn if OF reserved memory is beyond current coherent DMA", " mask", " - dma-coherent: report a failed reserved memory assignment", " - dmaengine: Fix device kref underflow in dma_chan_put()", " - dmaengine: fix use-after-free in dma_chan_put() and", " dma_release_channel()", " - dmaengine: wait for RCU readers before releasing dma_device", " - wifi: cfg80211: only group hidden BSSes with beacon entries", " - wifi: cfg80211: don't filter by BSS type when removing stale entries", " - wifi: mac80211: don't offload TC setup on AP_VLAN interfaces", " - wifi: mac80211: suppress chanctx warning for debugfs reset", " - wifi: mac80211: unlist vifs when their netdev is unregistered", " - wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping", " - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown", " - wifi: mac80211: require a peer station for TDLS setup confirm", " - wifi: mac80211: don't allow link changes when iface is down", " - wifi: mac80211: don't RCU-dereference the mesh CSA settings we just set", " - wifi: mac80211: don't access the TSF of a down interface", " - wifi: mac80211: add HE 6 GHz capability in the scan elems len", " - wifi: mac80211: mesh: release the channel if start fails", " - wifi: mac80211: set up the TX info early to fix failure paths", " - mm: memblock: show all region flags in debugfs", " - scsi: qla2xxx: Fix the ql2xfc2target parameter description", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse order", " - dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic", " DMA", " - RDMA/efa: Keep admin queues alive while IRQ is registered", " - RDMA/efa: Keep EQ resources alive while IRQ is registered", " - RDMA/siw: Bound fragmented header copies by the remaining length", " - netfilter: nft_nat: fully initialise new_addr in netmap setup", " - netfilter: flowtable: hold reference on ct until flow is released", " - perf/arm-cmn: Fix wp_dev_sel2 setting for multi-DTM configurations", " - drm: Fix drm_pending_vblank_event leak in error path for out_fence_ptr", " - keys: fix lost wakeup when reaping a dead key type", " - ALSA: bcd2000: Fix race between rawmidi and disconnect", " - phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflow", " - phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio setting", " - ALSA: pcm: set timer->private_data before registering the PCM timer", " - Input: trackpoint - fix the inertia attribute name in the ABI document", " - ALSA: 6fire: Clean ups with guard()", " - ALSA: usb: 6fire: Avoid embedded URBs", " - ALSA: 6fire: fix OOB write from device-reported iso length", " - wifi: virt_wifi: don't transfer operstate before register", " - drm/ast: Automatically clean up poll helper", " - drm/vc4: Use managed KMS polling to fix UAF on unbind", " - ALSA: hda: trace PCM open only after assigning a stream", " - btrfs: tree-checker: print dev extent offset in error message", " - drm/msm/dsi: round the byte clock rate after reparenting to the PHY PLL", " - seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation", " - ipv4: icmp: reject RTN_UNREACHABLE input routes in icmp_route_lookup", " - net: fddi: skfp: fix NULL deref when setting the MAC address while down", " - wifi: brcmfmac: fix lost 802.1x TX completion wakeup", " - net: bridge: mst: move switchdev call outside rcu", " - tcp: Don't call skb_clone_and_charge_r() for close()d listener in", " tcp_v6_do_rcv().", " - tcp: do not let tcp_rmem be set below 4096", " - ksmbd: return buffer overflow for partial filesystem info", " - ksmbd: fix partial file information responses", " - ksmbd: keep compound responses on query info errors", " - dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()", " - Bluetooth: ISO: Fix parent socket leak in iso_conn_ready()", " - Bluetooth: btmtk: fix wrong status for short WMT FUNC_CTRL events", " - Bluetooth: btmtksdio: Fix PM runtime reference leak in shutdown", " - Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup", " - pppoatm: ensure a writable skb header and linear data", " - drop_monitor: synchronize tracepoint unregistration on error path", " - drop_monitor: fix out-of-bounds write in reset_per_cpu_data()", " - KVM: PPC: Book3S HV: fix use-after-free in", " kvmhv_emulate_tlbie_all_lpid()", " - KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure", " - powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba", " - ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments", " - ASoC: hdmi-codec: Report a change when the channel status moves", " - net: netsec: fix device_node reference leak on phy_np", " - net: lock the socket in sock_gettstamp()", " - net: ethernet: cortina: Ack RX overrun interrupt correctly", " - net: macb: fix ordering around PTP timestamp read", " - net: mvpp2: prevent buffer overflow in page_pool allocation", " - drm/amdgpu: check ras and obj before dereference", " - btrfs: abort transaction on failure to update inode for hole punching", " and reflinking", " - mm/huge_memory: use folio's memcg inside __folio_split()", " - net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue", " - net: cpsw: Execute ndo_set_rx_mode callback in a work queue", " - wifi: rtw88: TX QOS Null data the same way as Null data", " - wifi: rtw88: Fix the random \"error beacon valid\" messages for USB", " - Input: xpad - add support for Victrix Pro BFG Controller", " - Input: xpad - add support for Azeron devices", " - Input: xpad - fix PDP Marvel Xbox 360 controller", " - ALSA: virtio: reset device before deleting virtqueues", " - ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type", " - ata: libahci: clear PxCLBU and PxFBU for AHCI_HFLAG_32BIT_ONLY", " - cifs: Fix server use-after-free in cifs_chan_skip_or_disable()", " - exec: Cleanup POSIX timers right after de_thread()", " - rds: ib: use rds_conn_drop() on protocol version mismatch", " - tcp: exclude old ACKs from tcp fast path", " - RDMA/ucma: Serialize join and leave on copy_to_user failure", " - RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()", " - openvswitch: avoid reallocating confirmed conntrack labels", " - net: xfrm: reject unrepresentable espintcp transport headers", " - HID: logitech-hidpp: fix race condition when accessing stale stack", " pointer", " - kselftest/arm64: Fix size of thread_data values for pthread_join()", " - arm64: hibernate: pass HVC_SET_VECTORS args to the resume hvc", " - arm64: dts: renesas: r8a779f0: Set UFS lane count", " - arm64: percpu: Fix this_cpu_write() casting", " - arm64: percpu: Fix this_cpu_and() mask generation", " - Bluetooth: btusb: fix NXP IW610 composite device handling", " - Bluetooth: eir: validate service data length before reading UUID", " - Bluetooth: hci_codec: validate vendor codec count length", " - Bluetooth: hci_sync: Serialize local codec list cleanup", " - dmaengine: sun6i: fix non-atomic read of DMA position registers", " - dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_status", " - dmaengine: ti: k3-udma-glue: fix NULL dereference in", " k3_udma_glue_release_rx_chn()", " - ipv6: xfrm: use full sockets in local error paths", " - net: lan743x: fix RX checksum use-after-free", " - net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb()", " - net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain", " - net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value", " - net/sched: hhf: cap hh_flows_limit at change time", " - net/packet: clear RX owner on VNET header error", " - net/packet: avoid truncating TPACKET_V3 private size", " - scsi: core: Validate MODE SENSE lengths in scsi_cdl_enable()", " - xfrm: serialize state GC with device state flush", " - memstick: ms_block: destroy io_queue workqueue on removal", " - mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio()", " - keys: translate request_key_auth pid for the reading procfs instance", " - KEYS: trusted: Fix tpm2_load_cmd() boundary check", " - i2c: at91: release DMA channels on remove and probe error", " - i2c: atr: fix dangling adapter pointer on add failure", " - i2c: imx: release DMA channels on probe error", " - i2c: imx: disable autosuspend on remove", " - IB/mlx4: Fix use-after-free on pkey sysfs registration failure", " - IB/hfi1: Resolve the credit-return buffer through the send context's", " node", " - IB/hfi1: Fix the PIO_CRED credit-return mmap", " - selinux: always fill AVC decision in avc_has_perm_noaudit()", " - mmc: core: Cancel SDIO IRQ work before freeing host", " - mmc: core: Fix OF node reference leak on card add failure", " - mmc: hsq: Fix use-after-free in retry work", " - mmc: mxcmmc: cancel data work and watchdog on remove", " - mmc: rtsx_pci_sdmmc: ignore broken write-protect on ThinkPad X260", " - mmc: sdhci-of-aspeed: Remove children before releasing SDC resources", " - mmc: sdio_uart: fix xmit_fifo leak when the port table is full", " - mmc: sh_mmcif: initialize IRQ-thread mutex before requesting interrupt", " - mmc: spi: reset bytes_xfered before retrying CRC failures", " - mmc: sdhci_am654: Reset command and data lines on failed tuning", " - Input: adp5588-keys - cache GPIO state before registering the gpiochip", " - Input: atkbd - skip deactivate for Xiaomi Redmi Book Pro 16 2026", " - Input: cyttsp5 - clamp the HID report size before memcpy", " - Input: evdev - zero absinfo before partial copy in EVIOCSABS", " - Input: i8042 - add quirk for Acer Aspire Go 15 AG15-42P", " - Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()", " - Input: soc_button_array - fix MS Surface Pro 11 probe failure", " - Input: soc_button_array - check btns_desc->package.count", " - Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)", " - Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound", " - Input: zero ff_effect before compat copy in input_ff_effect_from_user", " - hwmon: (hp-wmi-sensors) Fix use-after-free in fungible_show()", " - hwmon: (pmbus/core) increase number of phases and add new mask", " - hwmon: (pmbus/tps53679) Fix TPS53676 phase page decoding", " - hwmon: (pmbus/tps53679) Select page 0 for single-page TPS53676", " - hwmon: (w83791d) remove fan/pwm 4-5 sysfs group on remove", " - hwmon: (w83793) release probe data through kref", " - watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog", " - watchdog: digicolor: Avoid division by zero", " - watchdog: msc313e: Fix premature reset during timeout update", " - watchdog: msc313e: Propagate error code in resume()", " - watchdog: rtd119x: Avoid division by zero", " - watchdog: sp5100_tco: Fix pci_dev reference leak in sp5100_tco_init()", " - watchdog: starfive-wdt: Fix runtime PM leak in starfive_wdt_pm_start()", " - wifi: brcmsmac: fix UAF in brcms_free_timer()", " - wifi: iwlegacy: fix broadcast stations deallocation", " - wifi: libertas_tf: fix UAF in lbtf_free_adapter()", " - wifi: rsi: fix heap OOB write on key removal", " - wifi: wlcore: release runtime PM ref on regdomain config failure", " - wifi: wilc1000: fix out-of-bounds read in P2P public action frames", " - wifi: wilc1000: fix RX buffer OOB-write in wilc_wlan_handle_isr_ext()", " - wifi: p54: validate curve data length in the calibration curve", " converters", " - wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST", " - wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length", " - wifi: mwifiex: validate scan response extents", " - wifi: mwifiex: validate action frame fixed fields", " - wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver", " - drm/gud: fix out-of-bounds write in gud_plane_atomic_check()", " - drm/msm/adreno: fix autosuspend cleanup during teardown", " - drm/msm/hdmi_phy: fix runtime PM cleanup on probe failure", " - smb: client: cancel reconnect work in clean_demultiplex_info()", " - smb: client: fix rlist race and missing initialization", " - smb: client: reject short Next offsets in parse_server_interfaces()", " - smb: client: fix smbd_connection leak on cifs_get_tcp_session() error", " - smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs", " - smb: client: fix potential OOB read in smb3_enum_snapshots()", " - smb: client: fix server->total_read for compound encrypted PDUs", " - smb: client: fix missing lower-bound check on DFS referral string", " offsets", " - smb: client: fix missing iov bounds check in parse_posix_sids()", " - ipv6: mcast: Use in6_dev_get() in ipv6_dev_mc_dec().", " - ipv6: mcast: Don't hold RTNL for IPV6_ADD_MEMBERSHIP and", " MCAST_JOIN_GROUP.", " - ipv6: mcast: Don't hold RTNL for IPV6_DROP_MEMBERSHIP and", " MCAST_LEAVE_GROUP.", " - ipv6: mcast: Don't hold RTNL for MCAST_ socket options.", " - ksmbd: fix partial normalized name responses", " - spi: spi-zynqmp-gqspi: stop the controller on shutdown", " - selftests/landlock: Add layout1.refer_mount_root", " - spi: zynqmp-gqspi: Use devm_spi_alloc_host()", " - erofs: fix large folio race in erofs_fscache_req_complete", " - netfilter: nf_tables: Tolerate chains with no remaining hooks", " - netfilter: nf_tables: Simplify chain netdev notifier", " - remoteproc: qcom_q6v5_adsp: Fix iommu_unmap() usage", " - bpf: Fix bpf_skb_change_tail wrt csum partial skbs", " - bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL", " - selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tc", " - bpf: Fix divide-by-zero in btf_struct_walk()", " - bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy()", " - tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context", " - HID: elecom: fix bus type for M-XGL20DLBK", " - bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()", " - bpf: Fix out-of-bounds read of rtt_min in sock_ops", " - bpf, sockmap: Fix self-redirect copied_seq double-counting", " - pinctrl: meson: Fix typo in s4 group name", " - HID: amd_sfh: Validate PCI BAR size before mapping", " - KVM: arm64: vgic-its: Add stronger type-checking to the ITS entry sizes", " - KVM: arm64: vgic-its: Skip unreachable devices instead of failing the", " save", " - KVM: arm64: Return -EINVAL for an empty SMCCC filter range at base 0", " - squashfs: Add dictionary size range check to prevent shift-out-of-bounds", " - Bluetooth: SMP: reject Security Request over BR/EDR", " - Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel", " - cgroup: selftests: Move memcontrol specific helpers out of common", " cgroup_util.c", " - selftests: cgroup: give the O_TMPFILE open in get_temp_fd() a mode", " - scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume()", " - docs: s390/pci: Improve and update PCI documentation", " - s390/pci/docs: Fix sriov_numvfs attribute name", " - s390/cio: Fix cio_update_schib() to not cache invalid schib", " - s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points", " - s390/cio: Guard PMCW field accesses with dnv check", " - xsk: Use a 32-bit compare in xsk_map_gen_lookup", " - bpf: Skip unsettled links in link iterator", " - net/sched: cls_u32: fix manual hash table handle IDR aliasing", " - bpf: Restrict CO-RE poisoning to relocatable instructions", " - libbpf: Reject truncated ldimm64 CO-RE relocations", " - netfilter: flowtable: publish HW_DEAD after worker is done", " - netfilter: nfnetlink_queue: hold nfnl mutex in event notifier", " - netfilter: nft_synproxy: use the family-aware checksum helper", " - ipvs: revalidate ihl before icmp_send", " - netfilter: ctnetlink: fix suspicious RCU usage in expect_iter_name", " - arm64: io: Reject non-user protection in ioremap_prot()", " - ocfs2: make ocfs2_calc_xattr_init() return void", " - drm/nouveau/clk: fix list cursor use after loop in", " nvkm_clk_ustate_update", " - drm/nouveau/clk: don't clobber reclock status when restoring volt/fan", " - net/sched: act_ct: don't WARN on benign flow_offload_alloc() failure", " - net: gue: reject invalid REMCSUM offsets", " - net: Do not return value from init_dummy_netdev()", " - net: core: Fix documentation", " - net: create a dummy net_device allocator", " - net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically", " - net: ethernet: mtk_eth_soc: unregister net_devices in case of probe", " failure", " - ip6_gre: Call ip6erspan_tunnel_unlink_md() in ip6erspan_changelink().", " - sctp: avoid livelock while updating retransmit path", " - net: usb: catc: bound the RX packet length in catc_rx_done()", " - net/sched: sch_hfsc: bound the classify inner-filter walk with a drift", " budget", " - drm/virtio: fix object leak when drm_gem_handle_create() fails", " - drm/virtio: fix object leak in virtio_gpu_resource_create_ioctl()", " - drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()", " - drm/virtio: release the GEM object on virtio_gpu_vram_create() errors", " - drm/bridge: samsung-dsim: fix TE GPIO lifetime for host attach", " - Bluetooth: bnep: fix out-of-bounds reads on short RX/TX frames and", " control fallthrough", " - Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()", " - net: usb: sr9700: include receive overhead in the length check", " - tg3: clean up PHYLIB resources on probe failure", " - s390/debug: Do not register views for failed static debug areas", " - s390/debug: Fix NULL pointer dereference in debug_info_copy()", " - net: ethernet: ti: netcp: fix pm_runtime usage counter leak on error", " - genetlink: report the real command id for dump-only ops in policy dumps", " - bpf: Fix bounds check for skb-backed dynptrs", " - bpf: Fix bpf_sock context code generation", " - bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc", " - net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports", " - net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports", " - sctp: hold asoc or transport before mod_timer() in timer handlers", " - net: stmmac: selftests: Support running selftests on DSA conduits", " - net: stmmac: selftests: Check the dev->features for S-TAG offload", " testing", " - net: stmmac: selftests: Capture all packets for vlan checks", " - net: stmmac: dwmac4: Use the correct bufzise when the len is exactly 8K", " - bpf: Reject dev-bound-only programs on other devices", " - nfc: nfcmrvl: validate helper command length before pull", " - nfc: st21nfca: validate received frame size", " - nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()", " - selftests: nci: Correct pthread_create return value check", " - nfc: llcp: Fix race condition in accept_queue lifecycle", " - selftests: nci: Fix uninitialized family ID on missing attribute", " - selftests/nci: Fix out-of-bounds store on thread join", " - nfc: virtual_ncidev: Add missing ioctl compat handler", " - nfc: llcp: fix sdreq TLV list leak on parse/alloc/send failure", " - nfc: st21nfca: validate ISO15693 inventory length", " - nfc: llcp: fix -ENOMEM on connect with zero-length service name", " - nfc: llcp: fix WKS SAP hijacking via prefix match in nfc_llcp_wks_sap()", " - nfc: llcp: fix slab-out-of-bounds reads when logging service names", " - nfc: pn533: fix OOB read in pn533_acr122_is_rx_frame_valid()", " - net/sched: act_gate: budget the per-entry list in get_fill_size", " - veth: manage XDP program pointers during channel resize", " - net: skbuff: fix pull-bound underflow in skb_checksum_setup_ipv6()", " - vrf: Stop corrupting skb->csum when capturing CHECKSUM_COMPLETE packets", " - bpf: Fix immediate JMP JEQ/JNE on MIPS32", " - bpf: Fix BSWAP 32 and 16 on MIPS64", " - driver core: Make dev_err_probe() silent for -ENOMEM", " - driver core: Add device probe log helper dev_warn_probe()", " - tg3: use random MAC address when tg3_get_device_address fails", " - net: bcmgenet: fix 64-bit RTNL stats reading in ethtool on 32-bit", " systems", " - net: bcmgenet: initialize u64 stats seq counter for all queues", " - net: bcmgenet: move bcmgenet_power_up into resume_noirq", " - net: bcmgenet: allow return of power up status", " - net: bcmgenet: do not skip WoL power up on GENET V1", " - net: bcmgenet: validate Ethernet address in bcmgenet_set_mac_addr", " - net: bcmgenet: mask DMA_TIMEOUT_MASK when reading DMA_RING0_TIMEOUT", " - ip_gre: Reject enabling collect metadata through changelink", " - vxlan: use one headroom snapshot for neighbour replies", " - net: xps: reject an out of range traffic class", " - bonding: crypto offload enabled, non-offload slave failover, rekey", " failed", " - net: dsa: mt7530: fix NULL dereference on unbind of MT7531 and MT7621", " - tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack()", " - nfp: hold IPsec RX state under the XArray lock", " - net/smc: fix UAF on lgr list traversal in smcr_port_err()", " - tipc: Fix a data race on mon->peer_cnt in mon_timeout()", " - net: ethernet: stmmac: dwmac-rk: fix bulk clock leak when the PHY clock", " fails", " - llc: fix skb UAF and leaks on llc_mac_hdr_init() failure", " - bridge: check llc_mac_hdr_init() return value in br_send_bpdu()", " - net/sched: sch_teql: fix shadowed err in __teql_resolve()", " - vlan: ensure sufficient headroom in vlan_dev_hard_header()", " - autofs: fix sbi->pipe file reference leak in autofs_kill_sb()", " - perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted", " PERF_GLOBAL_CTRL bits", " - perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU", " has PEBS isolation, to fix stuck PEBS_ENABLED", " - perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS", " config) if PEBS is unused", " - perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs()", " - mptcp: return sk_wait_data() errors from recvmsg()", " - rculist: add list_splice_rcu() for private lists", " - x86/PCI: Disable enhanced atomics on AMD NBIO 7.7 and 7.11", " - tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers", " underflow", " - sctp: discard the rest of the packet on a stale-cookie error", " - af_packet: fix integer overflow in prb_calc_retire_blk_tmo()", " - ata: libata-scsi: bound the ATA passthru sense descriptor writes", " - fou: reject omitted FOU_ATTR_IPPROTO on FOU_ENCAP_DIRECT", " - writeback: bound cleanup_offline_cgwb() rescans by rotating scanned", " inodes", " - workqueue: Fix NULL current_pwq deref in flush dependency check", " - writeback: report a Tasks-RCU quiescent state per cgwb drain pass", " - fsl/fman: Fix clk reference leak in read_dts_node()", " - ipv6: do not let ipv6_find_hdr() return an offset past the packet end", " - ipv6: sr: enforce exact attribute length for SEG6_ATTR_DST", " - gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()", " - gpio: zynq: fix runtime PM leak on request error path", " - llc: reserve device headroom for allocated frames", " - rds: ib: Clear the sg list when mapping an MR fails", " - drm/i915: fix incorrect RCU teardown order", " - drm/amd/display: Fix dc stream excess put in dm_update_crtc_state()", " - drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init()", " - drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show()", " - drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init()", " - drm/nouveau: fix autosuspend cleanup during teardown", " - drm/nouveau: Fix bridge reference leak in nv1a_ram_new()", " - drm/nouveau: fix double-free in nvif_vmm_dtor", " - drm/nouveau: Fix gem reference leak in validate_init()", " - drm/nouveau: don't bump pin count on failed re-pin in", " nouveau_bo_pin_locked()", " - drm/virtio: fix memory leak of fence event on execbuffer failure", " - drm/virtio: fix NULL pointer dereference on fence allocation failure", " - gpio: tps65219: Fix GPIO input value reads", " - PCI: of_property: Omit bus properties without a subordinate bus", " - HID: alps: fix use-after-free on input2 registration failure", " - HID: quirks: add ALWAYS_POLL quirk for SDINNOVATION gaming keyboard", " - HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()", " - net/mlx5: Fix rev_entry reference leak in", " mlx5_tc_ct_shared_counter_get()", " - net/mlx5e: advertise MACsec offload only when supported", " - net/sched: reject IDR error pointers when deleting actions", " - net: arp: terminate device name before lookup", " - net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read", " - net: hisilicon: hns_dsaf_mac: fix mdio device leak in", " hns_mac_register_phy()", " - net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry", " - net: atl1c: fix soft lockup on out-of-range tpd_cons read", " - net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read", " - net: usb: cdc_mbim: add MeiG Smart SRM821 to ZLP whitelist", " - net: usb: lan78xx: Fix URB reference leak in", " lan78xx_submit_deferred_urbs()", " - netfilter: ip6t_rpfilter: reject routes without inet6_dev", " - netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read", " - nfc: fix use-after-free in nfc_get_local_general_bytes", " - nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()", " - nfc: port100: reject frames whose declared length exceeds the received", " data", " - scsi: libiscsi_tcp: Check the data direction of a Data-In PDU", " - pinctrl: single: free the IRQ on domain creation failure", " - s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()", " - RISC-V: KVM: Synchronize hrtimer callback during teardown", " - RISC-V: KVM: Fix HSM hart status error propagation", " - Bluetooth: hci_conn: fix CIS hold ownership on reuse", " - Bluetooth: hci_sock: validate event length before filtering", " - Bluetooth: hci_sock: reject out-of-range OCF values", " - Bluetooth: ISO: balance the parent hold in hci_bind_bis()", " - Bluetooth: L2CAP: validate frame length before control and FCS access", " - Bluetooth: mgmt: fix race in read_unconf_index_list()", " - Bluetooth: RFCOMM: fix NULL dereference of dlc->session in", " RFCOMM_CONNINFO", " - smb: client: fix create context out-of-bounds reads", " - smb: client: validate POSIX create context length", " - xfs: fix blockgc group quota scanning when usrquota isn't enforced", " - cxl/mem: Fix no cxl_nvd during pmem region auto-assembling", " - perf test: Change all remaining #!/bin/sh to #!/bin/bash", " - lan78xx: Enable 125 MHz CLK configuration for LAN7801 if NO EEPROM is", " detected", " - lan78xx: Enable Auto Speed and Auto Duplex configuration for LAN7801 if", " NO EEPROM is detected", " - usb: xhci: add tracing for PORTSC register writes", " - usb: xhci: add helper to read PORTSC register", " - usb: xhci: add USB Port Register Set struct", " - usb: xhci: implement USB Port Register Set struct", " - usb: xhci: use cached HCSPARAMS1 value", " - usb: xhci: simplify handling of Structural Parameters 1 values", " - vlan: defer real device state propagation to netdev_work", " - crypto: virtio - Less function calls in", " __virtio_crypto_akcipher_do_req() after error detection", " - crypto: virtio - Drop sign/verify operations", " - crypto: virtio - Drop superfluous [as]kcipher_ctx pointer", " - crypto: virtio - Drop superfluous [as]kcipher_req pointer", " - crypto: atmel-ecc - avoid stale fallback key after set_secret failure", " - net: mediatek: Fix potential NULL pointer dereference in dummy", " net_device handling", " - wifi: rtw89: disable CSI STBC for VHT 160MHz", " - soundwire: intel_auxdevice: add cs42l43 codec to wake_capable_list", " - soundwire: intel_auxdevice: Add cs42l43b to wake_capable_list", " - net: mana: hardening: Reject zero max_num_queues from", " MANA_QUERY_VPORT_CONFIG", " - s390/cio: Purge based on the cdev's online status", " - thunderbolt: Avoid reserved fields in path config space for USB4 routers", " - thunderbolt: Don't disable lane adapter if XDomain lane bonding isn't", " possible", " - drm/amd/display: Find link encoder for flexible DIG mapping cases", " - drm/panel: Enable GPIOLIB for panels which uses functions from it", " - wifi: mac80211: explicitly disable FTM responder on AP stop", " - media: qcom: camss: avoid format string warning", " - watchdog: imx7ulp_wdt: Keep WDOG running until A55 enters WFI on i.MX94", " - platform/chrome: Resolve kb_wake_angle visibility race", " - platform/x86: sel3350-platform: Retain LED state on load and unload", " - media: chips-media: wave5: Add range checks for dec_output_info", " - HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification", " - ASoC: Intel: sof_sdw: append dai type to dai link name unconditionally", " - drm/mediatek: dsi: Compress of_device_id entries and add sentinel", " - drm/mediatek: dsi: Add compatible for mt8167-dsi", " - iomap: don't make REQ_POLLED imply REQ_NOWAIT", " - iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfg", " - drm/imagination: Populate FW common context ID before passing to the FW", " - spi: dw-mmio: Add ACPI ID LECA0002 for LECARC SoCs", " - HID: bpf: Add Huion Inspiroy Frego M button quirk", " - ALSA: seq: prioq: Use guard() for locking", " - ALSA: seq: Remove arbitrary prioq insertion limit", " - drm/dp: Add DSC virtual DPCD quirk for Realtek MST branch device", " - drm/amd/display: Initialize dsc_caps to 0", " - net: sfp: add quirk for OEM 2.5G optical modules", " - drm/nouveau/bios: skip the IFR header if present", " - soc/tegra: fuse: Register nvmem lookups at probe", " - ACPI: scan: Honor _DEP for ACPI0016 PCI/CXL host bridge", " - powerpc/fadump: Add timeout to RTAS busy-wait loops", " - nvme: refresh multipath head zoned limits from path limits", " - usb: xhci: Improve Soft Retries after short transfers", " - net/mlx5: E-Switch, align disable sequence with switchdev-to-legacy", " transition", " - ipv6: use READ_ONCE() for bindv6only default in inet6_create()", " - riscv: panic if IRQ handler stacks cannot be allocated", " - RDMA/mlx5: Create ODP EQ for non-pinned dmabuf MRs", " - wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS", " - platform/x86: msi-ec: Add support for MSI Pulse GL66 12th Gen", " - wifi: mt76: mt7925: add Netgear A8500 USB device ID", " - wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec", " - wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv", " - fbcon: don't suspend/resume when vc is graphics mode", " - PCI: Avoid FLR for MediaTek MT7925 WiFi", " - hwmon: (raspberrypi) Fix delayed-work teardown race", " - btrfs: use on-disk uuid for s_uuid in temp_fsid mounts", " - net: lan966x: restore RX state on reload failure", " - HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost", " contacts", " - hwmon: (dell-smm) Add XPS 9315 to fan control whitelist", " - hwmon: (dell-smm) Add Dell Latitude 7320 to fan control whitelist", " - hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist", " - dmaengine: Fix spelling mistakes", " - dmaengine: altera-msgdma: Use memcpy_toio for descriptor FIFO writes", " - Bluetooth: btusb: MT7922: Add VID/PID 0e8d/223c", " - Bluetooth: btintel: Add support for Filmore Peak2 (BE201)", " - Bluetooth: btintel: Add support for Whale Peak2", " - Bluetooth: btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)", " - Bluetooth: btrtl: Add the support for RTL8922A", " - Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d922", " - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925", " - Bluetooth: btusb: MT7925: Add VID/PID 0e8d/8c38", " - Bluetooth: btusb: Add Realtek RTL8922AE VID/PID 0bda/d923", " - ipv6: Add ipv6_addr_{cpu_to_be32,be32_to_cpu} helpers", " - net: hns3: Use ipv6_addr_{cpu_to_be32,be32_to_cpu} helpers", " - net: hns3: improve the unused_tuple parameter setting", " - apparmor: propagate -ENOMEM correctly in unpack_table", " - bpftool: Pass host flags to bootstrap libbpf", " - leds: trigger: gpio: Use GPIOD_FLAGS_BIT_NONEXCLUSIVE", " - mailbox: imx: Use devm_pm_runtime_enable()", " - mailbox: imx: Add a channel shutdown field", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 16IAP7", " - rtc: mv: add suspend/resume support for wakeup", " - ceph: harden send_mds_reconnect and handle active-MDS peer reset", " - ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk", " - ALSA: hda/realtek: Add quirk for HP Victus 16-e0xxx (88EE) to enable", " mute LED", " - netfs: Fix decision whether to disallow write-streaming due to fscache", " use", " - ASoC: rt712-sdca: reset codec at io_init to fix silent headphone", " - ALSA: hda/realtek - Add quirk for HP Victus 15-fa0xxx (MB 8A50)", " - ALSA: hda: cs35l56: Fail if wmfw file is missing", " - cifs: Fix support for creating SFU fifo", " - wifi: iwlwifi: mvm: validate mac_link_id in session protect notif", " - wifi: iwlwifi: mvm: remove mvm prefix from iwl_mvm_tx_resp*", " - wifi: iwlwifi: mvm: parse beacon notif per layout", " - ata: libata-core: Disable LPM on some WD drives", " - ALSA: hda/realtek: Add mute LED quirk for HP Victus 16-e0xxx (MB 88ED)", " - ata: libata-core: Disable LPM on WD Green 2.5 480GB", " - ata: libata-core: Disable LPM on WDC WD141KFGX-68FH9N0", " - bpftool: Strip all -Wformat* flags from bootstrap libbpf build", " - drm/amd/display: clean-up dead code in dml2_mall_phantom", " - driver core: Move fw_devlink stuff to where it belongs", " - driver core: device.h: Group of_node handling declarations and", " definitions", " - driver core: Export get_dev_from_fwnode()", " - l2tp: Don't assign net->gen->ptr[] for pppol2tp_net_ops.", " - Bluetooth: btrtl: Add the support for RTL8852BT/RTL8852BE-VT", " - Bluetooth: btrtl: Add the support for RTL8761CUV", " - tcp: use GFP_ATOMIC in tcp_send_active_reset()", " - net: iptunnel: fix stale transport header during tunnel decapsulation", " - smb3: add dynamic tracepoint for reflink errors", " - smb3: add four dynamic tracepoints for copy_file_range and reflink", " - smb: client: batch SRV_COPYCHUNK entries to cut round trips", " - smb: move copychunk definitions to common/smb2pdu.h", " - smb/client: fix data corruption in emulated insert range", " - smb/client: fix integer truncation in collapse range", " - s390: Add get_lowcore() function", " - s390: Replace S390_lowcore by get_lowcore()", " - s390/vtime: Remove duplicate get_lowcore() calls", " - s390/vtime: Use __this_cpu_read() / get rid of READ_ONCE()", " - s390/time: Use jiffies instead of jiffies_64", " - ASoC: ux500: Deassert the MSP reset during probe", " - ASoC: ux500: Remove obsolete PRCMU QoS calls", " - ASoC: ux500: Allow repeated MSP prepare calls", " - arm64: trans_pgd: clone only the linear map that exists at runtime", " - nvme-tcp: open-code nvme_tcp_queue_request() for R2T", " - nvme-tcp: defer TLS inline send to io_work", " - ppp: ppp_synctty: simplify tty disc_data access", " - octeontx2-af: Fix limiting SRIOV VF count logic", " - bpf: Mark sched_process_wait argument as nullable", " - ASoC: topology: Constify an argument of snd_soc_tplg_component_load()", " - ASoC: Intel: avs: Constify struct snd_soc_tplg_ops", " - ASoC: Intel: avs: Do not ignore -ENOENT when loading a topology", " - thermal: sysfs: switch to use scnprintf() to suppress truncation warning", " - ethtool: Symmetric OR-XOR RSS hash", " - ethtool: Block setting of symmetric RSS when non-symmetric rx-flow-hash", " is requested", " - net: ethtool: copy the rxfh flow handling", " - net: ethtool: remove the duplicated handling from rxfh and rxnfc", " - net: ethtool: require drivers to opt into the per-RSS ctx RXFH", " - net: ethtool: add dedicated callbacks for getting and setting rxfh", " fields", " - eth: nfp: migrate to new RXFH callbacks", " - pds_core: don't release PCI regions for VFs on reset", " - af_unix: Return immediately when manage_oob() returns NULL for 0-length", " buffer.", " - idpf: account for VLAN header when parsing RSC packet header", " - Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware", " - Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset", " - Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset", " - mptcp: remove unneeded READ_ONCE() annotation", " - net: dsa: lantiq_gswip: deduplicate dsa_switch_ops", " - net: dsa: lantiq_gswip: Use dev_err_probe where appropriate", " - net: dsa: lantiq_gswip: Don't manually call gswip_port_enable()", " - net: dsa: lantiq_gswip: Use dsa_is_cpu_port() in gswip_port_change_mtu()", " - net: dsa: lantiq_gswip: Remove dead code from gswip_add_single_port_br()", " - net: dsa: lantiq_gswip: prepare for more CPU port options", " - net: dsa: lantiq_gswip: Consistently use macros for the mac bridge table", " - net: dsa: lantiq_gswip: move definitions to header", " - net: dsa: lantiq_gswip: fix GSWIP_MDIO_PHY_FCONTX_EN value", " - perf: Supply task information to sched_task()", " - cxgb4: clip_tbl: Fix spelling mistake \"wont\" -> \"won't\"", " - net: phy: mediatek: Re-organize MediaTek ethernet phy drivers", " - net: phy: add phy_disable_eee", " - net: phy: mediatek-ge: disable EEE on the MT7530 PHY", " - net: stmmac: TSO: Simplify the code flow of DMA descriptor allocations", " - net: stmmac: fix TSO support when some channels have TBS available", " - net: stmmac: add stmmac_tso_header_size()", " - net: stmmac: add TSO check for header length", " - scripts/mksysmap: fix escape of '$' in the __pi_ pattern", " - ring-buffer: Check resize_disabled before publishing the new subbuf", " order", " - s390/crypto: Fix skcipher_walk return code handling in aes_s390", " - s390/crypto: Fix use of mutex in atomic context", " - xfs: truncate quota file correctly when repairing quota file", " - xfs: fix bnobt repair space reservation disposal failure", " - xfs: fix backwards skipping logic in xrep_quota_block", " - xfs: compute dquot checksum after resetting dd_lsn in repair", " - smb: client: fix UBSAN array-index-out-of-bounds in smb2_copychunk_range", " - Revert \"arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entries\"", " - xdrgen: Fix union declarations", " - bpf: fix the return value of push_stack", " - ipv6: pass proto by value to ipv6_push_nfrag_opts() and", " ipv6_push_frag_opts()", " - ipv6: add some unlikely()/likely() clauses in ip6_output.c", " - inet: add dst4_mtu() and dst6_mtu() helpers", " - ipv6: adopt dst_dev() helper", " - ipv6: use dst6_mtu() instead of dst_mtu()", " - ipv4: use dst4_mtu() instead of dst_mtu()", " - net: advertise TCP MSS from the configured MTU, not the learned PMTU", " - mm: fix possible NULL pointer dereference in __swap_duplicate", " - mm, swap: ratelimit bad swap entry reports", " - mm: move hugetlb specific things in folio to page[3]", " - mm: move _pincount in folio to page[2] on 32bit", " - mm/gup: fix always draining LRU caches in", " collect_longterm_unpinnable_folios()", " - mm/slab: move and refactor __kmem_cache_alias()", " - mm/slub: fix missing debugfs entries for caches created before sysfs", " init", " - x86/locking: Remove semicolon from \"lock\" prefix", " - x86/locking: Use sfence for wmb() if SSE is available", " - xen/balloon: improve accuracy of initial balloon target for dom0", " - x86/xen: fix init of balloon stats again", " - cxl/pci: Remove unnecessary CXL Endpoint handling helper functions", " - cxl/pci: Remove unnecessary CXL RCH handling helper functions", " - cxl/pci: Remove CXL VH handling in CONFIG_PCIEAER_CXL conditional blocks", " from core/pci.c", " - zram: fixup read_block_state()", " - zram: remove entry element member", " - zram: use zram_read_from_zspool() in writeback", " - zram: switch to guard() for init_lock", " - NFSD: Rename a function parameter", " - NFSD: Make nfsd_genl_rqstp::rq_ops array best-effort", " - nfsd: dedup nfs4_client_to_reclaim inserts", " - nfsd: fix netlink dumpit error handling for rpc_status_get", " - nfsd: update mtime/ctime on COPY in presence of delegated attributes", " - nfsd: disallow file locking and delegations for NFSv4 reexport", " - ceph: Remove fs/ceph deadcode", " - ceph: force a cap message when a deferred revoke can't be acked", " immediately", " - HID: apple: preserve keyboard backlight across T2 resume", " - btrfs: constify pointer parameters where applicable", " - btrfs: move btrfs_is_empty_uuid() from ioctl.c into fs.c", " - btrfs: move BTRFS_BYTES_TO_BLKS() into fs.h", " - btrfs: move btrfs_alloc_write_mask() into fs.h", " - btrfs: expose per-inode stable writes flag", " - btrfs: update include and forward declarations in headers", " - btrfs: parameter constification in ioctl.c", " - btrfs: add forward declarations and headers, part 1", " - btrfs: pass struct btrfs_inode to btrfs_sync_inode_flags_to_i_flags()", " - btrfs: prepare btrfs_punch_hole_lock_range() for large data folios", " - btrfs: DEFINE_FREE for struct btrfs_path", " - btrfs: use BTRFS_PATH_AUTO_FREE in can_nocow_extent()", " - btrfs: add btrfs prefix to main lock, try lock and unlock extent", " functions", " - btrfs: rename extent map functions to get block start, end and check if", " in tree", " - btrfs: do not overwrite NODATASUM flag when removing NODATACOW flag", " - HID: sony: use guard() and scoped_guard()", " - HID: mcp2221: fix OOB write in mcp2221_raw_event()", " - NFSD: Consolidate the revocation-path client unpin", " - bpf: Factor stackid_init function from __bpf_get_stackid", " - bpf: Factor stackid_fastpath function from __bpf_get_stackid", " - bpf: Factor stackid_new_bucket from __bpf_get_stackid", " - bpf: Use stack id functions instead of __bpf_get_stackid", " - ACPI: TAD: Rearrange RT data validation checking", " - ACPI: TAD: Split three functions to untangle runtime PM handling", " - ACPI: TAD: Add locking around AML evaluations", " - cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register", " - ipv6: annotate data-races around devconf->rpl_seg_enabled", " - tcp: convert to dev_net_rcu()", " - ipv6: adopt skb_dst_dev() and skb_dst_dev_net[_rcu]() helpers", " - ipv6: ip6_mc_input() and ip6_mr_input() cleanups", " - SUNRPC: Introduce xdr_set_scratch_folio()", " - SUNRPC: Update svcxdr_init_decode() to call xdr_set_scratch_folio()", " - SUNRPC: make various functions static, or not exported.", " - rpc_populate(): lift cleanup into callers", " - rpc_mkpipe_dentry(): saner calling conventions", " - rpc_pipe: don't overdo directory locking", " - sunrpc: Add a helper to derive maxpages from sv_max_mesg", " - svcrdma: Adjust the number of entries in svc_rdma_recv_ctxt::rc_pages", " - ocfs2: validate dx_root extent list fields during block read", " - mm, hugetlb: increment the number of pages to be reset on HVO", " - SUNRPC: Restore NUMA_NO_NODE for svc thread allocations in global mode", " - landlock: Fix TCP Fast Open connection bypass", " - selftests/landlock: Add test for TCP fast open", " - selftests/landlock: Add missing connect(minimal AF_UNSPEC) test", " - s390/boot: Add sized_strscpy() to enable strscpy() usage", " - s390/boot: Avoid IPL parameter append past command line", " - wifi: mac80211: don't start a ROC while scanning", " - wifi: mac80211: don't warn when an IBSS has no channel to scan", " - wifi: mac80211: abort chanswitch when leaving a mesh", " - wifi: mac80211: reset state when starting AP fails", " - wifi: cfg80211: expose cfg80211_chandef_get_width()", " - wifi: mac80211: Add missing return value documentation", " - wifi: mac80211: don't allow injecting frames wider than the chanctx", " - wifi: mac80211: mesh: reset the CSA state when leaving", " - arm64: hibernate: clone only the linear map that exists at runtime", " - ASoC: Rename snd_soc_dai_link_ch_map.ch_mask to cpu_ch_mask", " - ASoC: Add codec_ch_mask to snd_soc_dai_link_ch_map", " - ASoC: soc-pcm: Apply snd_soc_dai_link_ch_map.codec_ch_mask to codec", " params", " - wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all()", " - Bluetooth: hci_core: Print number of packets in conn->data_q", " - Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained", " - Bluetooth: coredump: Quiesce dump work on unregister", " - Bluetooth: ISO: set BT_LISTEN before requesting a BIG sync", " - net: stmmac: do not overwrite phc_index when no PTP clock is registered", " - net: skbuff: do not leave stale header offsets after pskb_carve()", " - ALSA: core: Fix potential UAF after asynchronous card release", " - ata: libahci_platform: Fix device reference leak in", " ahci_platform_get_resources()", " - x86/microcode/intel: Reject problematic loading on Granite Rapids", " systems", " - net/sched: act_api: release tail references on DELACTION failure", " - xfrm: use hlist_del_init_rcu for state_cache and state_cache_input", " - KEYS: encrypted: fix integer overflow of datablob_len", " - HID: asus: fortify keyboard handshake", " - ALSA: hda/realtek: Limit Star Labs internal mic boost", " - ALSA: hda/realtek: Add StarFighter HDA SSID", " - xfrm: Refactor xfrm_input lock to reduce contention with RSS", " - xfrm: Fix dev use-after-free in xfrm async resumption", " - xfrm: save input state data before secpath resets", " - KVM: s390: Fix IRQ injection with SIGP Stop and Store Status", " - KVM: x86/pmu: Move Intel PMU global MSRs to intel_is_valid_msr()", " - bpf: Remove migrate_{disable|enable} in ->map_for_each_callback", " - bpf: Bail out early in __htab_map_lookup_and_delete_elem()", " - bpf: Factor out htab_elem_value helper()", " - bpf: Register dtor for freeing special fields", " - bpf: Fix UAF due to concurrent consumption of ttrace lists in alloc_bulk", " - HID: bpf: fix __hid_bpf_hw_check_params report length", " - RISC-V: KVM: Preserve firmware counter value across stop/start", " - RISC-V: KVM: Fix perf-backed counter accounting across stop and read", " - KVM: arm64: vgic-its: Free the caches when GITS_BASER changes", " - KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP", " - scsi: sd_zbc: Reject disks with too many zones", " - net/mlx5: devcom, Base component size on linked devices", " - drm/nouveau/disp: don't reject HDMI config on cards without SCDC", " - bpf: Bound ownership depth through local kptrs and graph roots", " - octeontx2-af: Fix memory scaling limitation in SR-IOV mode", " - dpll: use exact lookup for reference sync pin id", " - ipv6: Fix dst leak for uncached routes.", " - drm/i915/psr: Add new SU area calculation helper to apply workarounds", " - drm/i915/psr: Clear stale sel fetch enable bits on sel fetch disable", " - drm/imagination: clamp freelist reconstruction requests", " - x86/mce: Fix hardware debug register corruption on task migration", " - virtio_net: copy zerocopy frags in start_xmit without NAPI", " - tcp: prevent collapsing skbs across boundary in rtx queue", " - fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder", " syzbot's \"WARNING in do_new_mount\" saga", " - mctp: route: iterate socket tag list in mctp_lookup_prealloc_tag()", " - drm/imagination: Propagate map failures correctly from pvr_mmu_map_sgl()", " - drm/imagination: Fix page count for page table for map() interface", " - drm/amd/display: Bump frame warning limit for clang builds of dml", " - drm/nouveau/uvmm: fix UAF in nouveau_uvmm_sm when BO is in TTM_PL_SYSTEM", " - drm/nouveau: Fix runtime PM leak in nouveau_connector_detect()", " - drm/nouveau: RCU-free the scheduler-containing nouveau_sched", " - drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV", " - mm/hugetlb: preserve mremap address delta when skipping page tables", " - net: openvswitch: conntrack: remove 'add_helper' dead code", " - net: openvswitch: conntrack: fix helper UAF due to extensions realloc", " - net: bridge: mdb: restart port group walk after deletion", " - netfilter: nf_tables: skip expired catchall elements on insert and", " delete", " - perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()", " - perf/core: Run sched_task() for PMUs with only CPU-wide events", " - pinctrl: sunxi: Use devm_clk_get_enabled() helpers", " - pinctrl: sunxi: keep a shadow copy of the data register output latches", " - s390/vfio-ap: fix KVM GISC and page leak when queue removed from host", " config", " - KVM: Ensure memory attributes xarray nodes are accounted to the caller's", " memcg", " - KVM: Don't treat reserved xarray entries as having memory attributes", " - KVM: arm64: Fix spurious warning for benign stage 2 teardown race", " - smb: move SMB2 Status code to common header file", " - smb: client: clean up failed cached directory opens", " - xfs: fix attr fork block count checks in xrep_inode_blockcounts", " - xfs: check di_forkoff correctly in scrub", " - ring-buffer: Add helper functions for allocations", " - sched: Rework prev_balance() to avoid stale prev references", " - ASoC: codecs: aw88261: reduce log spam", " - ASoC: codecs: aw88261: only check PLL and clock state at power-up", " - dmaengine: Add devm_dma_request_chan()", " - i2c: mxs: fix DMA channel leak on probe error", " - firmware: qcom_scm: Rename peripheral as pas_id", " - remoteproc: pas: Replace metadata context with PAS context structure", " - remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check", " - power: supply: ab8500_fg: Remove redundant dev_err()/dev_err_probe()", " - iommu/msm: Use helper function devm_clk_get_prepared()", " - platform/x86: ISST: Check for admin capability for write commands", " - platform/x86: ISST: Validate max level for set feature", " - PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder", " value", " - platform/x86: think-lmi: Fix current password length check", " - platform/x86: think-lmi: improve check if BIOS account security enabled", " - platform/x86: think-lmi: Fix certificate thumbprint sysfs output", " - platform/x86: intel_sar: Check ACPI_HANDLE() against NULL", " - platform/x86/amd/pmc: Move STB block into amd_pmc_s2d_init()", " - platform/x86/amd/pmc: Move STB functionality to a new file for better", " code organization", " - platform/x86/amd/pmc: Define enum for S2D/PMC msg_port and add helper", " function", " - platform/x86/amd/pmc: Restore msg_port on amd_stb_s2d_init() error paths", " - io_uring/waitid: have io_waitid_complete() remove wait queue entry", " - io_uring/waitid: avoid siginfo copy during ring teardown", " - net/smc: Address spelling errors", " - net/mlx5e: SHAMPO, Always calculate page size", " - net/mlx5e: do not HW-GRO coalesce small frames", " - ALSA: hda/ext: preserve PPLCCTL bits when clearing reset", " - hwrng: stm32 - Fix runtime PM cleanup on registration failure", " - wifi: mt76: mt7915: set correct background radar capability", " - udf: Move udf_map_block() up", " - udf: Fix data loss when converting inline inodes to out of line", " - usb: dwc3: gadget: Reinitiate stream for all host NoStream behavior", " - wifi: rtw89: cleanup unused rtwdev::roc_work", " - wifi: rtw89: Hide some errors when the device is unplugged", " - usb: typec: tcpm: fix debug accessory mode detection for sink ports", " - usb: typec: tcpm: constrain TCPM_SOURCING_VBUS event handling", " - xhci: Cleanup Candence controller PCI device and vendor ID usage", " - usb: cdns3: rename hibernated argument of role->resume() to lost_power", " - usb: cdnsp: fix wakeup from S3 after controller context loss", " - staging: rtl8723bs: fix spacing around operators", " - staging: sm750fb: fix mono image source stride mismatch in", " lynxfb_ops_imageblit()", " - tracing/probes: Fix anon_stack check for unnamed bitfields in", " btf_find_struct_member", " - Documentation: tracing: Add documentation about eprobes", " - tracing/probes: Fix BTF kflag check for anonymous struct member access", " - tracing: Clean up use of trace_create_maxlat_file()", " - ftrace: Fix most kernel-doc warnings", " - dma-buf: align fd_flags and heap_flags with dma_heap_allocation_data", " - compiler_types: Move lock checking attributes to compiler-context-", " analysis.h", " - futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling", " - rtc: rzn1: Handle unset alarm weekday in rzn1_rtc_read_alarm", " - perf/aux: Allocate non-contiguous AUX pages by default", " - perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities", " - nvme: all namespaces in a subsystem must adhere to a common atomic write", " size", " - nvme: refactor the atomic write unit detection", " - nvme: fix atomic write size validation", " - nvme: skip the zoned limits update if the zone info query failed", " - mm: fix incorrect vm_flags usage when checking allowable orders for", " tmpfs", " - nvdimm: preserve flush callback -ENOMEM", " - nvdimm: virtio_pmem: stop allocating child flush bio", " - nvdimm: virtio_pmem: always wake -ENOSPC waiters", " - nvdimm: virtio_pmem: use READ_ONCE()/WRITE_ONCE() for wait flags", " - mtd: rawnand: pl353: Add message about ECC mode", " - mtd: rawnand: pl353: Make sure we use the monolithic helpers for raw", " accesses", " - clk: qcom: Fix test_ctl_hi field for DEFAULT_EVO PLLs", " - ASoC: tegra210_mixer: sort the register default table", " - ASoC: tegra: Fix the MIXER enable default value", " - mm/mremap: reset unfaulted VMA page offset for MREMAP_DONTUNMAP", " - KVM: x86/mmu: Dynamically allocate shadow MMU's hashed page list", " - KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into \"front\" and \"back\"", " halves", " - KVM: x86: Extract REGS and SREGS runtime sync code to helpers", " - KVM: x86: Rename __{g,s}et_sregs2() =>", " kvm_vcpu_ioctl_x86_{g,s}et_sregs2()", " - KVM: x86: Check EFER validity on KVM_SET_SREGS*", " - media: i2c: imx355: Replace client->dev usage", " - media: imx355: Avoid calling imx355_power_off twice in error path", " - media: rkvdec: Propagate platform_get_irq() errors", " - KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported", " - scsi: qla2xxx: Use ring-slot helpers in __qla2x00_alloc_iocbs", " - scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot", " - scsi: qla2xxx: Fix 64G link speed reporting in get_data_rate", " - scsi: qla2xxx: Clamp max_npiv_vports to VP_CTRL bitmap capacity", " - f2fs: clean up F2FS_I()", " - f2fs: convert F2FS_I_SB to sbi in f2fs_setattr()", " - f2fs: don't allow unaligned truncation to smaller/equal size on pinned", " file", " - f2fs: fix to avoid potential section-unaligned pinfile", " - f2fs: dirty directory inodes on mtime/ctime update", " - f2fs: Convert clear_node_page_dirty() to clear_node_folio_dirty()", " - drm/amdgpu: Fix missing unwind in amdgpu_ib_schedule() error path", " - drm/amdgpu: add a helper to calculate ring distance", " - drm/amdgpu: plumb timedout fence through to force completion", " - drm/nouveau/disp/r535: Add scanline position support + head state", " support", " - drm/amd/display: Set gpuvm min page size to 4K on dcn35/36", " - drm/sysfb: simpledrm: Improve panel-size validation", " - firmware: sysfb: Move bpp-depth calculation into screen_info helper", " - drm/sysfb: simpledrm: Improve framebuffer-size validation", " - drm/sysfb: ofdrm: Fix is_avivo() constant comparison bug", " - configfs:get_target() - release path as soon as we grab configfs_item", " reference", " - ipmr: Simplify the allocation of slab caches", " - ip6mr: Simplify the allocation of slab caches in ip6_mr_init", " - kernel misc: Remove the now superfluous sentinel elements from ctl_table", " array", " - sysctl: move the \"cad_pid\" entry from pid_table[] to kern_reboot_table[]", " - tracing: Constify struct event_trigger_ops", " - tracing: Remove get_trigger_ops() and add count_func() from trigger ops", " - tracing: Merge struct event_trigger_ops into struct event_command", " - virtio-mmio: Remove virtqueue list from mmio device", " - virtio_mmio: disable IRQ wake before free_irq", " - tools/bootconfig: Cleanup bootconfig footer size calculations", " - tools/bootconfig: Fix integer overflow and truncation in size checks", " - EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout", " - EDAC/altera: Use parent device for devres in altr_portb_setup()", " - drm/bridge: tc358768: Enforce input bus flags via atomic_check", " - net: macb: Replace open-coded implementation with napi_schedule()", " - net: macb: Use netif_napi_add_tx() instead of netif_napi_add() for TX", " NAPI", " - net: macb: unify device pointer naming convention", " - net: macb: initialize PTP state before registering clock", " - erofs: add sysfs feature entry for xattr prefixes", " - idpf: Fix kernel-doc descriptions to avoid warnings", " - idpf: introduce idpf_q_vec_rsrc struct and move vector resources to it", " - ipv6: make ipv6_pinfo.saddr_cache a boolean", " - ipv6: reorganise struct ipv6_pinfo", " - ipv6: Move ipv6_fl_list from ipv6_pinfo to inet_sock.", " - mptcp: pm: drop match in userspace_pm_append_new_local_addr", " - sock: add sock_kmemdup helper", " - mptcp: use sock_kmemdup for address entry", " - mptcp: pm: userspace: fix address ID overflow", " - mptcp: pm: reset retrans_time when ADD_ADDR entry is reused", " - mptcp: pm: use for_each_subflow helper", " - mptcp: pm: rename add_entry structure to add_addr", " - mptcp: export mptcp_subflow_early_fallback()", " - tcp: introduce icsk->icsk_keepalive_timer", " - mptcp: do not reschedule the RTX timer for fallback sockets", " - smb: client: refactor ACL setting control flow in id_mode_to_cifs_acl()", " - smb/client: fix security flag calculation when setting security", " descriptors", " - xfs: strengthen the \"is cow staging\" helpers in scrub", " - xfs: fix backwards mergeability logic in refcount scrubber", " - phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context", " - ALSA: usb-audio: Optimize the copy of packet sizes for implicit fb", " handling", " - ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity", " - swiotlb: use the adjusted address for the highmem page lookup", " - net: phy: mediatek: do not report link and per-speed LED rules together", " - btrfs: take commit root semaphore when iterating in", " mark_block_group_to_copy()", " - arm64: Use load LSE atomics for the non-return per-CPU atomic operations", " - arm64: percpu: Fix LSE operations on {8,16}-bit types", " - i2c: qcom-cci: Stop complaining about DT set clock rate", " - i2c: qcom-cci: Remove the unused variable cci_clk_rate", " - i2c: qcom-cci: fix device_node refcount leak in cci_probe()/cci_remove()", " - driver core: bus: add irq_get_affinity callback to bus_type", " - PCI: hookup irq_get_affinity callback", " - blk-mq: introduce blk_mq_map_hw_queues", " - scsi: replace blk_mq_pci_map_queues with blk_mq_map_hw_queues", " - scsi: fnic: Fix missed link-up when critical IRQ targets offline CPU", " - Input: hp_sdc - shut down kicker timer on module exit", " - wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown", " - hwmon: (pwm-fan) Stop RPM timer before freeing tach data", " - wifi: libipw: reject TKIP frames without a full MIC", " - wifi: mac80211: track MU-MIMO configuration on disabled interfaces", " - wifi: mac80211: refuse to make a monitor active when it has no queue", " - smb: mark the new channel addition log as informational log with", " cifs_info", " - smb: client: fix use-after-free of iface in cifs_try_adding_channels()", " - drm/amdgpu: Failed to check various return code", " - drm/amdgpu/umsch: remove vpe test from umsch", " - drm/amdgpu: use GFP_NOWAIT for memory allocations", " - drm/amdgpu: fix rmmio iounmap skipped on device removal", " - smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs()", " - drm: add drm_memory_stats_is_zero", " - drm/amdgpu: hold a runtime PM reference for P2P dma-buf attachments", " - smb: client: fix reparse buffer bounds in cifs_query_reparse_point()", " - smb/client: send lease break ACKs thru correct session for multiuser", " mounts", " - vlan: require the MAC header to be present in __vlan_insert_inner_tag()", " - bna: prevent IOC timer rearm during teardown", " - i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL", " - drm/amdgpu: Fix acpi device leak in amdgpu_acpi_enumerate_xcc()", " - drm/i915/mst: add mst sub-struct to struct intel_dp", " - drm/i915/dp_mst: Fix configuring FEC for a disconnected stream", " - mm/rmap: allocate anon_vma_chain objects unlocked when possible", " - mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma", " publish", " - mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()", " - mm/hugetlb: fix surplus pages in dissolve_free_huge_page()", " - mm/hugetlb: create hstate_is_gigantic_no_runtime helper", " - mm/hugetlb: do not dissolve gigantic pages without runtime support", " - super: make iterate_supers_type() deletion-safe", " - PCI: Fix Resizable BAR restore order", " - PCI: Fix BAR resize for devices on a root bus", " - packet: use ubuf_info completion for TX_RING packets", " - HID: hid-alps: Use pm_ptr instead of #ifdef CONFIG_PM", " - HID: alps: unregister DualPoint Stick input device on remove", " - net/sched: act_ct: fix helper UAF due to extensions realloc", " - net/sched: act_ct: avoid modifying shared unconfirmed ct entry", " - net: ipconfig: Remove outdated comment and indent code block", " - net: ipconfig: bound DHCP option construction", " - net: ena: Remove autopolling mode", " - net: ena: fix MMIO read buffer leak on probe failure", " - RISC-V: KVM: Fix null pointer dereference in", " kvm_riscv_aia_imsic_rw_attr()", " - RISC-V: KVM: Serialize IMSIC attributes with vCPU migration", " - rose: fix dev_put() leak in rose_loopback_timer()", " - rose: hold loopback neighbour reference across timer callback", " - rose: fix race between loopback timer and module removal", " - rose: clear neighbour pointer after rose_neigh_put() in state machines", " - rose: guard rose_neigh_put() against NULL in timer expiry", " - rose: fix netdev double-hold in rose_rx_call_request()", " - rose: fix notifier unregistered too early in rose_exit()", " - rose: fix netdev double-hold in rose_make_new()", " - rose: drop CALL_REQUEST in loopback timer when device is not running", " - rose: cancel neighbour timers in rose_neigh_put() before freeing", " - nvme: revert the cross-controller atomic write size validation", " - bootconfig: Fix negative seeks on 32-bit with LFS enabled", " - tracing: Move d_max_latency out of CONFIG_FSNOTIFY protection", " - mtd: rawnand: pl353: Fix debug prints", " - platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails", " - usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due", " to race condition", " - bpf: Reject key-less BTF for hash maps", " - mm/hugetlb: keep max_huge_pages when dissolving surplus folios", " - Upstream stable to v6.6.158, v6.12.111, v6.12.112", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97559", " - smb: client: fail DACL rewrite when the new DACL exceeds 64K", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97566", " - mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97594", " - landlock: Fix use-after-free of the source's parent directory", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97597", " - ipv6: flowlabel: cap duplicate leases per socket", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97609", " - netfilter: cttimeout: prevent UAF during module unload", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74347", " - netfilter: cttimeout: detach dataplane timeout policy and repurpose", " refcount", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97620", " - drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97615", " - net: bridge: use option bits for CFM/MRP frame handlers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97906", " - bootconfig: Fix integer overflow in initrd size check", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97619", " - io_uring/rw: end write accounting from ->ki_complete", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97901", " - genetlink: pin family module during policy dump", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97918", " - tracing: Undo the registration when enabling the histogram trigger fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97919", " - tracing: Take the reference before publishing the named histogram", " trigger", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97933", " - tracing: Take trace_array reference when opening a tracer options file", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97935", " - tracing: Set the trace clock before registering the histogram trigger", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97949", " - configfs: unhash the dentry before dropping the item in rmdir", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97938", " - reboot: fix cad_pid use-after-free race", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97939", " - ipmr: account multicast table and route memory", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97934", " - tracing: Fix memory corruption from a \"STACKTRACE\" histogram key", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97950", " - configfs: pin the symlink target's dirent instead of chasing ->ci_dentry", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89806", " - drm/sysfb: ofdrm: Fix integer overflow in fb_size calculation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93244", " - drm/sysfb: simpledrm: Improve stride validation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89827", " - drm/amdgpu: avoid force-completing uninitialized UVD rings", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97534", " - f2fs: accurately adjust free_sections during free_segment_range", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89832", " - f2fs: fix to clear dirty flag on folio in error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93285", " - f2fs: embed f2fs_gc_kthread in f2fs_sb_info", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89837", " - f2fs: fix dentry folio leak in find_in_level", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89838", " - f2fs: limit recovery filename logging to stored length", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89840", " - f2fs: validate MOVE_RANGE destination size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97529", " - scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97527", " - scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97528", " - scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97530", " - scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97531", " - scsi: qla2xxx: Skip vport under deletion in report ID acquisition", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89868", " - media: chips-media: wave5: Add timeout while stop_streaming", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97535", " - scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97532", " - scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97536", " - scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97537", " - scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89859", " - scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89921", " - KVM: s390: Zero initialize data structures for inject_pfault_token", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93196", " - nvdimm: virtio_pmem: refcount requests for token lifetime", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98161", " - nvdimm: pmem: keep PREFLUSH before data writes", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89956", " - s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev", " objects", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89972", " - nvme: add missing SRCU grace period in error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89996", " - dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90002", " - ftrace: Take trace_array reference before accessing its ftrace_ops", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90013", " - tracing: Take trace_array reference when opening options file", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90016", " - staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90023", " - usb: gadget: f_mass_storage: fix null pointer dereference in", " fsg_common_set_num_buffers()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90029", " - usb: storage: realtek_cr: fix use-after-free on disconnect", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80935", " - wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE", " copy", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80939", " - wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on", " reboot", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90030", " - usb: dwc3: clear forceRM when issuing EndTransfer", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93200", " - i3c: master: Fix use-after-free of master->this", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80937", " - wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE", " copy", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93199", " - i3c: master: Do not treat master device as a duplicate target", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80980", " - net/smc: stop killed, freed and out_of_sync sharing a byte", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89467", " - power: supply: qcom_battmgr: fix use-after-free", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-81016", " - platform/x86/amd/pmc: Propagate SMU errors and validate S2D address", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89437", " - platform/x86: int1092: Fix potential memory leak in sar_probe()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89795", " - PCI: Allow per function PCI slots to fix slot reset on s390", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89441", " - mmc: via-sdmmc: cancel card-detect work on remove", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89452", " - iommu/msm: Unwind probe state on registration failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89797", " - power: supply: ab8500_fg: fix use-after-free on remove", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93231", " - lockd: fix swapped arguments in nlmsvc_match_ip()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89500", " - ring-buffer: Make cpu_buffer::free_page a buffer_data_read_page", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89520", " - sched/core: Make core-sched flips wait for in-flight selections", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89503", " - ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2025-37807", " - bpf: Fix kmemleak warning for percpu hashmap", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72315", " - smb: client: fix busy dentry warning on unmount after DIO", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89492", " - ocfs2: validate directory-index entry counts when reading metadata", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93228", " - svcrdma: Reject Write/Reply chunks with segcount 0", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89543", " - sunrpc: fix use-after-free in __rpc_clnt_handle_event and", " __rpc_clnt_remove_pipedir", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89544", " - SUNRPC: fix gssx_dec_option_array error path bugs", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89545", " - sunrpc: defer rq_argp and rq_resp free until after RCU grace period", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89564", " - ip: orphan prefetched skbs before multicast forwarding", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89561", " - ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89799", " - bpf: Disable preemption in bpf_get_stackid", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89572", " - cpufreq: apple-soc: Fix OPP table cleanup", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90037", " - NFSD: Prevent client use-after-free during close_lru reaping", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90036", " - NFSD: Prevent client use-after-free during blocked-lock reaping", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89622", " - HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90041", " - HID: sony: clean up device list on probe failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89624", " - HID: universal-pidff: stop the device when force-feedback init fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89625", " - HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89644", " - btrfs: fix extent map leak in NOCOW direct I/O write", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90042", " - ceph: properly decrypt filenames in vmalloc() buffers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89659", " - NFSD: Prevent client use-after-free during delegation revoke", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89676", " - nfsd: fix stale s2s_cp_stateids IDR entry for async COPY", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89685", " - nfsd: fix clock domain mismatch in clients_still_reclaiming()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89708", " - nfsd: RCU-protect cl_cb_session to fix use-after-free on session", " teardown", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89698", " - nfsd: widen nfsd_genl_rqstp address fields to sockaddr_storage", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2025-40210", " - Revert \"NFSD: Remove the cap on number of operations per NFSv4 COMPOUND\"", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89693", " - nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89717", " - zram: set default primary compressor in zram_destroy_comps()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89718", " - zram: fix out-of-bounds access in writeback_store()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89719", " - zram: fix out-of-bounds access in read_block_state()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90044", " - usb: gadget: f_fs: Fix Use-After-Free in AIO error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-90045", " - USB: gadget: ffs: fix mm lifetime handling", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89731", " - cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89755", " - mm/migrate_device: clear stale mapping after freeing swapcache", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89763", " - KEYS: trusted: Fix TPM teardown ordering", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80945", " - crypto: iaa - unmap dst before software fallback on decompress", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80847", " - tcp: clamp route advmss to TCP_MIN_MSS", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97545", " - xfs: don't leak new_bp if xfs_btree_bload_drop_buf fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97552", " - xfs: initialise error in xfs_defer_finish_one()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97583", " - afs: Clear stale peer app data after address list changes", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97584", " - afs: Fix incorrect free in candidate cleanup in afs_lookup_server()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97587", " - perf: RISC-V: store available counter mask as bitmap", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97605", " - erofs: preserve LZMA decoders on resize failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97606", " - fs: autofs: fix memory leak in autofs_fill_super()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97616", " - net/sched: act_api: release all action references on NEWACTION failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97902", " - fs: don't return -EINVAL for successful nested thaw", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97908", " - Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97915", " - accel/ivpu: Limit firmware log name prints to field size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97916", " - accel/ivpu: Validate firmware log buffer metadata", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97917", " - accel/ivpu: Validate full buffer range in ivpu_to_cpu_addr", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97929", " - ALSA: usbusx2y: validate URB actual_length in interrupt callback", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97953", " - net: stmmac: fix TX descriptor availability check for TSO traffic", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97961", " - perf/core: Allow list_del during perf_event_overflow()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97965", " - vxlan: initialize _md in vxlan_xmit_one()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97978", " - eth: ice: don't dereference pointers from TP_printk()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97985", " - af_unix: Update last skb marker in manage_oob().", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97992", " - vhost-vdpa: protect config_ctx from being freed under the config", " callback", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98018", " - net: mctp: i3c: serialize probe with bus removal", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98021", " - net: reject oversized tx_queue_len at netlink parse time", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98028", " - eth: nfp: drop the replaced rule from the list when reprogramming fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98029", " - eth: nfp: bound the ntuple rule dump by the caller's buffer size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98037", " - bpf: Reject untrusted allocated-object pointers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98039", " - bpf: Require MEM_PERCPU for percpu kptr stores", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98041", " - bpf: Don't predict JMP32 pointer vs zero comparisons", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98054", " - ASoC: Intel: avs: Fix unbalanced module reference count", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98056", " - nvme: remove stale namespaces by NSID range during scan", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98081", " - btrfs: zoned: finish active block group cleanup if call_zone_finish()", " fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98097", " - tipc: Dont send random pad bytes in RESET/ACTIVATE messages", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98103", " - igmp: convert struct ip_sf_list to RCU", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98107", " - Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98114", " - ksmbd: propagate DACL parsing errors", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98126", " - smb/client: validate new EOF for zero range", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98127", " - smb/client: validate new EOF for insert range", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98151", " - bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74735", " - l2tp: fix tunnel and session refcount leak on seq_file release", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72438", " - md/raid10: fix writes_pending and barrier reference leaks on discard", " failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-68303", " - drm/vc4: hvs/v3d: Fix null dereference in unbind", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93793", " - wifi: iwlwifi: mvm: validate TX_CMD response layout", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93796", " - wifi: iwlwifi: pcie: null RX pointers after free", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93801", " - smb/client: zero-initialize stack-allocated cifs_open_info_data", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93804", " - wifi: mac80211: ibss: wait for in-flight TX on disconnect", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93817", " - perf: Fix addr_filter_ranges lifetime", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93828", " - exfat: fix handling of damaged volume in exfat_create_upcase_table()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97412", " - pds_core: quiesce DMA before freeing resources", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97428", " - drm/amdgpu: harden FRU PIA parsing with bounded helpers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97473", " - powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97492", " - wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not", " needed", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97494", " - drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97505", " - PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97514", " - media: chips-media: wave5: Fix Reports from Kernel Lock Validator", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97518", " - wifi: cfg80211: reject duplicate wiphy cipher suite entries", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97520", " - gfs2: move quota_init qc iterator increment", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80836", " - crypto: virtio - bound the akcipher result length", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80925", " - vlan: fix skb_under_panic and races when toggling HW VLAN offload", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80841", " - net/packet: defer vmalloc TX_RING free until skbs finish", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80861", " - usb: xhci: bail out of setup if the controller is inaccessible", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2025-40097", " - ALSA: hda: Fix missing pointer check in hda_component_manager_init", " function", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-52988", " - netfilter: nf_tables: join hook list via splice_list_rcu() in commit", " phase", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98102", " - ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98101", " - ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97523", " - mptcp: close race between scheduler and state change", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97524", " - mptcp: avoid unneeded actions on subflow reset", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97522", " - mptcp: fix bad accounting in __mptcp_subflow_push_pending()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74496", " - fou: Fix use-after-free in fou_create()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93286", " - net: appletalk: fix NULL pointer dereference in aarp_send_ddp()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93287", " - i2c: smbus: reject oversized block transfers in the common path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97931", " - ALSA: us122l: Prevent write upgrades for read mappings", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97540", " - net: usb: pegasus: don't rely on id table pointer arithmetic", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97541", " - wifi: ath9k_htc: don't store usb_device_id", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97539", " - usb: xusbatm: don't rely on id table pointer arithmetic", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97542", " - xfs: bail out on bitmap errors in xrep_agfl_fill", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97555", " - smb: client: fix heap overflow in DACL owner/group rewrite", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97556", " - smb: client: avoid leaking refcount when cifs_sb_tlink() fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97557", " - smb: client: avoid leaking refcount in cifs_queue_oplock_break()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97560", " - smb: client: fix one-byte OOB read in smb2_parse_native_symlink()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97562", " - smb: client: pin DFS superblock in iterator callback", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97564", " - smb: client: reject userspace cifs.idmap descriptions", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97568", " - mptcp: syncookies: remember the request backup flag", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97572", " - bnxt_en: Propagate RX ring init failures in bnxt_init_nic()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97573", " - bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97575", " - media: v4l2-ctrls: validate AV1 tile counts", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97576", " - media: v4l2-ctrls: validate HEVC tile counts", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97577", " - media: verisilicon: rockchip: reject AV1 frames exceeding the tile", " capacity", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97578", " - media: verisilicon: rockchip: guard VPU981 AV1 divisor and tile buffer", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97579", " - media: mediatek: vcodec: bound AV1 tile-start copy to the array capacity", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97581", " - media: verisilicon: hantro: bound G2 HEVC tile loop to the buffer", " capacity", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97582", " - hwmon: (gpio-fan) Fix use-after-free in alarm work", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97592", " - s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm", " algorithm", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97595", " - mac802154: fix use-after-free of sdata via queued RX frames", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97596", " - ipvs: reject invalid states in connection template sync records", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97598", " - ipv4: fib: bound automatic table ID allocation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97599", " - ieee802154: hwsim: serialize pib updates to fix double-free", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97601", " - ieee802154: 6lowpan: fix NULL dereference in lowpan_newlink", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97602", " - inet: frags: invalidate queues before flushing them", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97604", " - fbdev: vfb: defer cleanup until the last reference", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97607", " - vdpa: ifcvf: Put device on unsupported feature error", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97608", " - netfilter: nf_log: unregister loggers before per-net teardown", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97611", " - net: openvswitch: fix use-after-free of the flow table mask array", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97612", " - net: mpls: clear inner_protocol when the last label is popped", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97613", " - net: mana: Reserve extra CQ slot for the fence completion CQE", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97899", " - drm/i915: Fix memory leak in query_perf_config_list()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97900", " - drm/drm_exec: fix up contended obj when num_objects is 0", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97904", " - cpufreq: initialize policy rwsem before sysfs publication", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97905", " - cpufreq: zero-initialize policy cpumask before sysfs publication", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97907", " - Bluetooth: btrtl: Don't leak return code when parsing firmware format v2", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97909", " - ASoC: sti: initialize IRQ lock before requesting IRQ", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97910", " - ASoC: sprd: validate compress buffer sizes against fixed allocations", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97920", " - tracing: Keep the entry count when the histogram stats allocation fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97921", " - tracing: Free histogram the field rejected for a bad modifier", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97922", " - tracing: Free histogram var refs regardless of how often they are", " referenced", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97923", " - tracing: Free histogram the var ref when its initialization fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97924", " - tracing/user_events: Don't destroy fields when event removal fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97925", " - tick/broadcast: Plug clockevents replacement race", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97926", " - ufs: validate cylinder group metadata before caching it", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97927", " - ufs: create the root dentry after loading cylinder metadata", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97930", " - ALSA: usbusx2y: fix in04_last array size mismatch with in04_buf", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97936", " - tracing: Fix memory corruption from the histogram stacktrace modifier", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97940", " - ipv6: fix fib6 walker UAF on seq stop", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97945", " - x86/mm: Fix user-space data loss with MADV_FREE and THP", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97948", " - powerpc/eeh: Fix recursive locking on devices without EEH sensitive", " driver", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89792", " - ksmbd: prevent out-of-bounds reads in share config responses", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97951", " - scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97952", " - sunvdc: unmap LDC cookies when the descriptor send fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97954", " - net/rds: fix tcp stream corruption with large pages", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97957", " - net: hinic: fix mailbox segment buffer overflow", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97958", " - net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97959", " - net/sched: cls_route: free emptied bucket on filter move", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97963", " - net: stmmac: initialize ptp_lock at probe time", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97964", " - ppp_synctty: ensure a writeable skb header", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97966", " - octeontx2-pf: reset HTB scheduler topology before freeing queues", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97969", " - watchdog: msc313e: Fix clock leak and spurious timer in settimeout()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97970", " - watchdog: msc313e: Avoid division by zero", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97973", " - net: macb: destroy the phylink instance on the probe error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97977", " - Bluetooth: btusb: Fix UAF of btusb_data by rx_work", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97979", " - ice: add missing xa_destroy for sched_node_ids", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97981", " - net: ethernet: cortina: Count dropped frames as NAPI work", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97982", " - net: ethernet: cortina: Fix budget accounting", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97984", " - net: ipv6: Fix UDP length overflow with PMTU discover and big MTU", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97986", " - virtio_input: stop callbacks before unregistering input device", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97987", " - virtio_input: reset device if input_register_device() fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97990", " - vdpa_sim_net: check TX pull result before RX copy", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97991", " - vdpa_sim_blk: reject out-of-range sector starts", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97993", " - vhost-vdpa: don't install the eventfd_ctx_fdget() error in config_ctx", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97994", " - vhost/vdpa: reject VRING_NUM larger than device max", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97995", " - virtio_console: do not free control-out buffers on remove", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97998", " - netfilter: nfnetlink_log: cope with concurrent instance destruction", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98006", " - ALSA: caiaq: Decoupling ep1_in_urb in caiaq dev", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98007", " - bpf: Reject non-scalar bpf_loop iteration counts", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98008", " - net: macb: fix NULL pointer dereference on unbind with fixed-link", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98009", " - net/sched: ets: clamp quantum in parse and fallback paths", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98010", " - net/sched: drr: clamp quantum in change class", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98011", " - net/sched: hhf: clamp quantum in change and init paths", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98012", " - net/sched: sfq: clamp quantum in change path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98013", " - net/sched: fq_pie: clamp quantum in change path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98014", " - net/mlx5: E-Switch, prevent mc_list repopulation during vport disable", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98015", " - net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98016", " - net/mlx5e: Fix use-after-free race in sample_restore_put()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98017", " - net/sched: defer qdisc freeing after failed creation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98020", " - pds_core: fix cmd_regs access racing BAR unmap on reset", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98022", " - net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98023", " - vxlan: reject dynamic fdb entries that reference a nexthop id", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98024", " - s390/ism: folio_put() after error", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98025", " - net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent", " partial_data heap overflow", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98026", " - net: bridge: mcast: properly convert mglist to rcu", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98027", " - net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer", " size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98030", " - net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98031", " - nexthop: Initialize extack in remove_nh_grp_entry()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98046", " - bpf: Mark bpf_btf_find_by_name_kind() as sleepable", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98051", " - net: bcmasp: fix tx_spb_ring_full() checking same slot cnt times", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98052", " - net: bcmasp: clear txcb->last before writing each descriptor", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98055", " - ASoC: Intel: avs: Clean up the bus when fetching ML caps fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98063", " - bpf: Fix NULL-ptr-deref in btf_var_show()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98064", " - bpf: Fix NULL-ptr-deref when showing a void BTF type", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98066", " - ALSA: caiaq: Fix potential double-free at error path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98068", " - net/rds: don't let rds_conn_shutdown() consume a concurrent drop", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98069", " - net/rds: acquire the fastpath locks in rds_conn_shutdown()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98070", " - net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98071", " - net/rds: clear cp_flags bits individually in rds_conn_path_reset()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98072", " - net/rds: use wq_has_sleeper() in release_in_xmit()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98074", " - bonding: do not clear curr_active_slave prematurely when releasing all", " slaves", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98075", " - bpf: reject BPF_PSEUDO_FUNC reference to the main program", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98076", " - tracing/probes: Fix use-after-free on field name/type of events with", " multiple probes", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98077", " - netfilter: nf_conntrack_sip: fix OOB read in sip_skip_whitespace()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98078", " - ipvs: fix reversed sequence option serialization", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98080", " - btrfs: do not force reloc root creation during qgroup_account_snapshot()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98082", " - btrfs: fix the possible bioc_list memory leak during error", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98083", " - btrfs: fix transaction use-after-free in raid stripe insertion", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98086", " - ALSA: ump: do not touch legacy_rmidi before it exists", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98088", " - scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in", " _base_assign_reply_queues()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98089", " - bonding: alb: fix uninitialized transport header access in", " alb_determine_nd()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98090", " - btrfs: restore active device pointers after failed sprout", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98091", " - btrfs: detach failed sprout device from transaction update list", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98092", " - ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98094", " - staging: fbtft: make dirty_lock IRQ-safe", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98095", " - af_packet: Don't cast tpacket_hdr.tp_len to int in", " tpacket_parse_header().", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98096", " - ipv6: sr: restore network header before routing and forwarding", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98098", " - tipc: fix NULL deref in tipc_named_node_up() on empty publication list", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98104", " - net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98108", " - Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98109", " - Bluetooth: hci_core: Fix race condition during device registration", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98111", " - Bluetooth: btintel: validate version TLV value lengths", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98113", " - ksmbd: rate limit unmapped SID errors", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98116", " - ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98121", " - watchdog: msc313e: Fix NULL pointer dereference in PM callbacks", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98122", " - vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98123", " - sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98128", " - scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98129", " - scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98130", " - sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98142", " - drm/cirrus-qemu: Validate BAR0 size during probe", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98154", " - nvme-rdma: fix -EIO cleanup order in queue_rq", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98155", " - accel/qaic: Address potential out-of-bounds read in resp_worker()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98157", " - EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-89796", " - mm/damon/core: avoid infinite kdamond_merge_regions() internal loop", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-80521", " - af_unix: Unlink scc_entry in unix_del_edge().", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74521", " - ksmbd: use memcmp() to compare ClientGUIDs", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74294", " - ASoC: meson: aiu: Validate written enum values", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74291", " - ASoC: topology: Check PCM and DAI name strings before use", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74289", " - ipv4: fib: Don't dump dying fib_info in fib_leaf_notify().", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-74258", " - bpf: Guard __get_user acesss with access_ok for uprobe_multi data", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72496", " - RDMA/bnxt_re: Proper rollback if the ioremap fails", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72485", " - coresight: platform: defer connection counter increment until alloc", " succeeds", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72413", " - sctp: fix err_chunk memory leaks in INIT handling", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72402", " - bpf: Mask pseudo pointer values in verifier logs", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-72334", " - Bluetooth: ISO: fix malformed ISO_END/CONT handling", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-68289", " - tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-68288", " - net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-68287", " - drop_monitor: fix size calculations for 64-bit attributes", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-68286", " - drop_monitor: perform u64_stats updates under IRQ-disabled section", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98158", " - ppp_async: drop the errored frame instead of resetting its headroom", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-98159", " - wifi: mt76: mt7921: validate CLC firmware records", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93288", " - netfilter: nfnetlink_log: wait for rcu grace period before freeing", " pernet state", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93781", " - scsi: core: Do not block on tag allocation in scsi_eh_lock_door()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93782", " - vhost-scsi: flush backend after device ioctls", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93783", " - Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93784", " - wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93785", " - cifs: validate idmap key payload length", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93786", " - ksmbd: preserve VFS inherited POSIX ACL mask", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93787", " - smb: client: bound dirent name against end of SMB response in", " cifs_filldir", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93788", " - wifi: iwlwifi: acpi: validate WGDS table revision index", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93789", " - wifi: iwlwifi: bound aligned TLV advance in FW parser", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93790", " - wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93791", " - wifi: iwlwifi: mvm: add a check on the tid coming from the firmware", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93792", " - wifi: iwlwifi: mvm: fix a possible underflow", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93794", " - smb/client: flush dirty data before punching a hole", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93795", " - blk-cgroup: fix leaks and online flag on radix_tree_insert failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93797", " - wifi: iwlwifi: mvm: fix an off-by-1 boundary check", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93798", " - btrfs: fix reloc root cleanup in merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93799", " - wifi: iwlwifi: mvm: validate sta_id in BA window status notif", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93800", " - btrfs: fix use-after-free on reloc root after error in", " insert_dirty_subvol()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93802", " - wifi: rsi: validate beacon length before fixed buffer copy", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93803", " - wifi: libipw: fix key index receive bound checks", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93805", " - wifi: cfg80211: validate rx/tx MLME callback frame lengths before access", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93806", " - wifi: cfg80211: validate assoc response length before status and IE", " access", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93807", " - wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93808", " - ALSA: usb-audio: caiaq: validate EP1 reply lengths", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93809", " - drm/amdgpu: flush pending RCU callbacks on module unload", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93810", " - cachefiles: Fix double fput", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93811", " - ksmbd: Fix acl.sd_buf memory leak and invalid sd_size error handling", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93812", " - ksmbd: fix sd_ndr.data memory leak in ksmbd_vfs_set_sd_xattr", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93813", " - btrfs: tree-checker: validate INODE_REF's namelen", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93814", " - spi: core: Abort active target transfer on controller suspend", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93815", " - net: au1000: move free_irq out of the close-time spinlocked section", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93816", " - f2fs: validate inline dentry name lengths before conversion", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93819", " - PCI: mediatek: Protect root bus removal with rescan lock", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93820", " - PCI: rockchip: Protect root bus removal with rescan lock", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93821", " - PCI: altera: Protect root bus removal with rescan lock", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93822", " - PCI: iproc: Protect root bus removal with rescan lock", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93823", " - drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO", " ioctl", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93824", " - tls: reject the combination of TLS and sockmap", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93825", " - spi: Add NULL check for spi_get_device_id() in", " spi_get_device_match_data()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93826", " - HID: hidpp: fix potential UAF in hidpp_connect_event()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93829", " - smb: client: fix races in cifsd thread creation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-93830", " - net: stmmac: xgmac2: disable RBUE in default RX interrupt mask", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97407", " - ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in", " set_fmt", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97408", " - Bluetooth: L2CAP: validate connectionless PSM length", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97409", " - nvme-fc: Do not cancel requests in io target before it is initialized", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97411", " - net: ibm: emac: mal: fix potential system hang in mal_remove()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97413", " - RDMA/rtrs-srv: Fix integer underflow in process_read and process_write", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97415", " - btrfs: tree-checker: validate names in ROOT_REF and ROOT_BACKREF", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97416", " - btrfs: balance: fix potential bg lookup failure in", " btrfs_may_alloc_data_chunk()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97417", " - netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97418", " - ALSA: es18xx: check control allocation before private data setup", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97419", " - hsr: broadcast netlink notifications in the device's net namespace", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97420", " - bpf: NUL-terminate replaced sysctl value", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97421", " - RDMA/umem: Be careful about boundary conditions in", " ib_umem_find_best_pgsz()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97425", " - drm/amdgpu: fix buffer overflow during vBIOS update", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97427", " - drm/amd/pm: bound pp_dpm_set_pp_table() memcpy", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97429", " - drm/amdkfd: fix UAF race in destroy_queue_cpsch", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97430", " - xhci: Prevent queuing new commands if xhci is inaccessible", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97434", " - dpaa2-switch: fix handling of NAPI on the remove path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97435", " - net: dsa: sja1105: flower: reject cross-chip redirect", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97436", " - dpaa2-switch: rework FDB management on the bridge leave path", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97437", " - ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97438", " - fs/ntfs3: validate index entry key bounds", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97439", " - fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97440", " - net: qrtr: fix node refcount leak on ctrl packet alloc failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97441", " - ata: ahci: fail probe if BAR too small for claimed ports", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97442", " - wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97443", " - perf/ftrace: Fix WARNING in __unregister_ftrace_function", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97444", " - ACPICA: add boundary checks in two places", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97445", " - ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97446", " - ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97447", " - ACPICA: Enhance OEM ID and Table ID validation in", " acpi_ex_load_table_op()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97448", " - ACPICA: Add validation for node in acpi_ns_build_normalized_path()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97449", " - ACPICA: Add package limit checks in parser functions", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97450", " - ACPICA: validate handler object type in two places", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97451", " - ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97452", " - ACPICA: Prevent adding invalid references", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97453", " - ACPICA: validate byte_count in acpi_ps_get_next_package_length()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97454", " - ACPICA: add boundary checks in acpi_ps_get_next_field()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97455", " - ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97456", " - ACPICA: Fix condition check in acpi_ps_parse_loop()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97472", " - ipv6: addrconf: fix temp address generation after prefix deprecation", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97475", " - thermal/drivers/tegra/soctherma: Switch to devm cooling device", " registration", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97476", " - rds: filter RDS_INFO_* getsockopt by caller's netns", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97481", " - serial: 8250: fix possible ISR soft lockup", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97482", " - usb: gadget: goku_udc: avoid NULL deref of dev->driver in INT_USBRESET", " log", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97483", " - usb: core: hcd: fix possible deadlock in rh control transfers", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97484", " - usbip: vhci_hcd: fix NULL deref in status_show_vhci", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97485", " - omfs: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97486", " - hpfs: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97487", " - jfs: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97488", " - qnx4: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97489", " - bfs: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97490", " - affs: handle set_blocksize failures", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97491", " - net/rds: Don't sleep inside rds_ib_conn_path_shutdown", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97495", " - drm/amdkfd: Check bounds on allocate_doorbell", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97496", " - drm/amdkfd: Fix OOB memory exposure in get_wave_state()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97497", " - drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97500", " - wifi: rtw89: phy: check length before parsing PHY status IE", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97502", " - mmc: davinci: avoid NULL deref of host->data in IRQ handler", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97506", " - crypto: ixp4xx - fix buffer chain unwind on allocation failure", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97507", " - media: dm1105: fix missing error check for dma_alloc_coherent", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97508", " - thunderbolt: Set tb->root_switch to NULL when domain is stopped", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97509", " - thunderbolt: Keep XDomain reference during the lifetime of a service", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97510", " - thunderbolt: Release request if tb_cfg_request() fails in", " __tb_xdomain_response()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97512", " - spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97516", " - wifi: rtw88: Add NULL check for chip->edcca_th in", " rtw_fw_adaptivity_result()", "", " * Noble update: upstream stable patchset 2026-10-07 (LP: #2169853) //", " CVE-2026-97517", " - wifi: nl80211: reject beacons with bad HE operation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822)", " - Revert \"arm64: mm: Don't remap pgtables for allocate vs populate\"", " - net: dst: introduce dst->dev_rcu", " - perf test: Simplify metric value validation test final report", " - perf test: raise limit to 20 percent for perf_stat_--bpf-counters_test", " - perf test bpf-counters: Add test for BPF event modifier", " - perf test stat_bpf_counter.sh: Stabilize the test results", " - mfd: tps6594: Add register definitions for TI TPS65224 PMIC", " - regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators", " - regulator: tps6594-regulator: Fix the number of irqs for TPS65224 and", " TPS6594", " - perf cs-etm: Create decoders after both AUX and HW_ID search passes", " - nvmet-rdma: use sbitmap to replace rsp free list", " - arm64: dts: qcom: sc8180x-lenovo-flex-5g: move pinctrl to appropriate", " nodes", " - arm64: dts: qcom: sc8180x: Enable the power key", " - irqdomain: Introduce irq_domain_free()", " - irqdomain: Introduce irq_domain_instantiate()", " - irqdomain: Handle additional domain flags in irq_domain_instantiate()", " - irqdomain: Handle domain hierarchy parent in irq_domain_instantiate()", " - irqdomain: Introduce init() and exit() hooks", " - irqdomain: Add support for generic irq chips creation before publishing", " a domain", " - wifi: iwlwifi: mei: add support for SAP version 4", " - RDMA/core: Add an option to display driver-specific QPs in the rdmatool", " - firmware: arm_scmi: Add multiple protocols registration support", " - wifi: ath11k: refactor ath11k_wmi_tlv_parse_alloc()", " - wifi: ath11k: implement handling of P2P NoA event", " - rcu: Rename rcu_momentary_dyntick_idle() into rcu_momentary_eqs()", " - arm64: dts: qcom: sm8550: Use GIC-ITS for PCIe0 and PCIe1", " - arm64: dts: qcom: sm8550: Fix the msi-map entries", " - selftests: mm: support shmem mTHP collapse testing", " - selftests/bpf: Limit URLS parsing logic to actual scope in vmtest", " - selftests/bpf: Support local rootfs image for vmtest", " - selftests/bpf: Add description for running vmtest on RV64", " - scsi: ufs: core: Remove unnecessary wmb() after ringing doorbell", " - null_blk: add configfs variable shared_tags", " - hwmon: (emc1403) Convert to with_info API", " - hwmon: (emc1403) Support 11 bit accuracy", " - hwmon: (emc1403) Add support for EMC1428 and EMC1438.", " - net: hsr: Use full string description when opening HSR network device", " - net: hsr: Provide RedBox support (HSR-SAN)", " - fuse: use FUSE_ROOT_ID in fuse_get_root_inode()", " - selftests: mm: cow: flag vmsplice() hugetlb tests as XFAIL", " - ACPI: processor: idle: Remove redundant cstate check in", " acpi_processor_power_init", " - ACPI: processor: idle: Optimize ACPI idle driver registration", " - ACPI: processor: idle: Move max_cstate update out of the loop", " - ACPI: processor: idle: Remove redundant static variable and rename", " cstate check function", " - irqdomain: Make build work for CONFIG_GENERIC_IRQ_CHIP=n", " - wifi: ath11k: Fix error handling in ath11k_wmi_p2p_noa_event()", " - net: hsr: enable promiscuous mode on interlink port with fwd offload", " - net: hsr: init prune_proxy_timer sooner", " - nvmet-rdma: fix queue leak when connect backlog is exceeded", " - net: openvswitch: fix kernel-doc warnings in internal headers", " - netfs: Fix netfs_read_folio() to wait on writeback", " - mm/page_vma_mapped: use huge_ptep_get() for hugetlb", " - fsnotify: inotify: pass mark connector to fsnotify_recalc_mask()", " - net: ntb_netdev: Fix TX busy and drop handling", " - clk: qcom: gcc-mdm9607: Increase delay for USB PHY reset", " - usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns()", " - thermal/drivers/imx: Disable clock on runtime resume failure", " - thermal/drivers/qoriq: Disable clock on resume failure", " - spi: bcm63xx-hsspi: disable clocks on resume failure", " - spi: bcm63xx: disable clock on resume failure", " - spi: bcmbca-hsspi: disable clocks on resume failure", " - spi: Fix DMA mapping ownership on partial map failure", " - mm/damon/sysfs-schemes: kobject_del() scheme dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme filter dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs", " - mm/damon/sysfs-schemes: kobject_del() scheme region dirs", " - mm/damon/sysfs: kobject_del() region and target (error) dirs", " - mm/damon/sysfs: kobject_del() target (normal), context and kdamond dirs", " - mm/damon: move kunit tests to tests/ subdirectory with _kunit suffix", " - mm/damon/core-kunit: check region count before testing in split_at()", " - ftrace: Synchronize the initialization of ftrace_ops", " - dmaengine: dw-edma: Fix HDMA channel status register access", " - dmaengine: dw-edma: Complete descriptors before pausing", " - block: flag zoned disks with GENHD_FL_NO_PART", " - ata: ahci: work around lost interrupts on Marvell 88SE61xx", " - irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout", " - Input: aiptek - validate raw macro indices before updating state", " - memcg: make the v1 soft limit knob inert", " - rtc: rzn1: Fix weekday underflow when alarm crosses month boundary", " - rtc: rzn1: Disable alarm interrupt before reprogramming alarm registers", " - arm64: mm: Fix the lockless page-table walk in show_pte()", " - ALSA: rawmidi: Return the error from snd_rawmidi_input_params()", " - nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails", " - Revert \"irqchip/mbigen: Fix mbigen node address layout\"", " - mm/hugetlb: fix missing migratable flag on same-node hugetlb migration", " - parisc: Fix alignment of asm statements in head.S", " - powerpc/pseries: Handle and log pseries-wdt registration failures", " - powerpc/pseries: Move H_WATCHDOG definitions to a common header", " - powerpc/crash: stop watchdogs before booting kdump kernel", " - s390/vfio-ap: Fix stale do_remove flag across iterations in", " vfio_ap_mdev_cfg_remove", " - s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap", " - s390/vfio-ap: Fix required lock not held during update of ap_matrix_mdev", " object", " - batman-adv: mcast: ensure unshared skb for multicast packets", " - batman-adv: bla: prevent CRC corruptions after claim flush", " - clk: qcom: gcc-msm8916: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-msm8939: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src", " - clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src", " - clk: qcom: gcc-mdm9607: Drop incorrect system_noc_bfdcd_clk_src", " - clk: qcom: gcc-mdm9607: Fix enable_reg for gcc_blsp1_sleep_clk", " - clk: qcom: gcc-mdm9607: Fix halt_reg for gcc_apss_axi_clk", " - clk: qcom: gcc-mdm9607: Drop incorrect BIMC PLL and related clocks", " - i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure", " - ASoC: fsl: mpc5200-i2s: Free DMA resources on probe failure", " - ASoC: hdac_hda: improve error logs", " - AsoC: intel: sst: fix PCI device reference leak on probe failure", " - ASoC: loongson: Fix error handling in ACPI property parsing", " - ASoC: samsung: aries_audio_probe: double of_node_put due to direct", " assignment without of_node_get", " - iio: adc: max34408: add missing 'select REGMAP_I2C' to Kconfig", " - iio: gyro: mpu3050: fix sign of raw angular velocity readings", " - iio: light: cm32181: return zero after writing calibscale", " - iio: light: gp2ap002: Disable regulators on resume failure", " - iio: pressure: mpl115: Fix runtime PM cleanup", " - iio: srf04: fix pm_runtime handling on probe error path", " - iio: temperature: hid-sensor-temperature: switch to non-devm", " iio_device_register()", " - iio: light: opt4001: Fix power down clearing bits of the wrong register", " - iio: light: opt4001: Fix incompatible pointer type passed to", " div_u64_rem()", " - iio: light: opt4001: Reject integration times with a non-zero seconds", " part", " - iio: light: opt4001: Fix reversed GENMASK() arguments in fault count", " mask", " - KVM: nVMX: Decouple INVVPID operand checks from flushing of vpid02", " - KVM: x86: Serialize writes to disabled_quirks using kvm->lock", " - KVM: x86: Ensure runtime reads of disabled_quirks are resolved once", " - KVM: s390: Zero initialize irq in reinject_machine_check", " - KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP", " - KVM: s390: Restore sigset on error path", " - LoongArch: Fix acpi_package_ids[] array overflow", " - LoongArch: Do not select HAVE_RUST when KASAN is enabled", " - media: amphion: Remove obsolete frame_count check in venc_start_session", " - media: cec: meson: ao-cec-g12a: name the CEC core regmap to avoid", " debugfs clash", " - media: i2c: alvium: Fix: Correct name of register in", " alvium_set_ctrl_auto_exposure", " - media: i2c: imx415: Return test pattern write errors", " - media: meson: vdec: fix NULL pointer deref in vdec_try_fmt_common", " - media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar", " routing", " - media: nxp: imx8-isi: Correct color map between V4L2 and ISI", " - media: nxp: imx8-isi: Use BIT_ULL() for 64-bit stream masks", " - media: v4l2-ctrls: Allow unknown HDR10 white point and luminance", " - media: venus: fix payload size returned by parse_caps() and", " parse_alloc_mode()", " - media: venus: fix payload size calculation in parse_raw_formats()", " - media: vimc: fix pixel format lookup in enum_framesizes", " - scsi: qla2xxx: Fix Name Server logout detection on FWI2 adapters", " - scsi: qla2xxx: Check entry_status in qla24xx_modify_vp_config()", " - scsi: qla2xxx: Fix response queue over-consumption in", " __qla_consume_iocb()", " - media: chips-media: wave5: Guard bit depth check with", " initial_info_obtained", " - scsi: qla2xxx: Fix NVMe abort reference leak on repeated abort", " - scsi: qla2xxx: Drop vport reference under lock in report ID acquisition", " - scsi: qla2xxx: Use coherent DMA buffer for D_Port diagnostics", " - f2fs: return symlink writeback errors", " - f2fs: reject overlapping move range after len expansion", " - f2fs: return writeback error from collapse range", " - f2fs: use new ioprio Macro to get ckpt thread ioprio level", " - f2fs: fix i_size when pinned fallocate partially fails", " - f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page()", " - f2fs: fix to zero post-EOF data when extending file size", " - drm/bridge: dw-hdmi: fix i2c adapter leak on probe failure", " - drm/ssd130x: fix column and row end address in partial updates for", " ssd132x", " - drm/sun4i: fix refcount leak in sun4i_backend_init_sat()", " - drm/hibmc: Fix list of formats on the primary plane", " - drm/hibmc: Use drm_atomic_helper_check_plane_state()", " - drm/gud: validate TV mode names before creating enum property", " - drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value", " - drm/amdgpu: check thunderbolt before switcheroo registration", " - drm/amdgpu: fix autosuspend cleanup during removal", " - drm/amdgpu: Skip accessing psp rum time db for APUs", " - drm/amdgpu: use AMDGPU_GPU_PAGE_SHIFT instead of PAGE_SHIFT", " - drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore", " - drm/amdkfd: Reject zero-sized AQL queue allocations after size halving", " - drm/nouveau: remove nouveau_chan.device", " - drm/nouveau: remove chan->drm", " - drm/nouveau: Use write-combined maps for coherent", " - mm/damon/vaddr: drop last same folio access check optimization", " - mm/damon/ops-common: use nr_accesses moving sum for quota score", " - mm/damon/paddr: drop last same folio access check reuse optimization", " - mm/damon/vaddr-kunit: check region count in three_regions test", " - mm/damon/core-kunit: handle region split failure in filter_out()", " - mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of()", " - batman-adv: fix TX priority extraction for BATADV_FORW_MCAST", " - mm/damon/core: skip aging from repeated aggressive merging", " - drm: Remove unused header in drm_dumb_buffers.c", " - drm: lcdif: Wait for vblank before disabling DMA", " - drm/v3d: Replace a global spinlock with a per-queue spinlock", " - drm/v3d: Store the active job inside the queue's state", " - drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format", " - drm/bridge: cdns-mhdp8546: Return an error pointer on allocation failure", " - smack: simplify write handlers of sysfs entries", " - smack: deduplicate smackfs/{direct,mapped} file_operations", " - smack: restrict smackfs/{direct,mapped} values to 0-255", " - x86/cfi: Use symmetric SYM_START and SYM_END in __CFI_TYPE()", " - HID: nintendo: Fix imu_timestamp_us double increment per report", " - soc: samsung: exynos-pmu: fix of_node refcount leak in", " exynos_get_pmu_regmap()", " - media: cec-pin: Fix event FIFO ordering", " - clk: versaclock7: Fix APLL clock leak on probe failure", " - clk: moxart: remove unused variables, fix refcount leak", " - clk: nuvoton: ma35d1: fix ignored div_u64 return values in PLL freq", " calculation", " - clk: nuvoton: ma35d1: fix PLL_CTL1_FRAC bit field width and fractional", " calc", " - clk: nuvoton: ma35d1-pll: convert from round_rate() to determine_rate()", " - clk: nuvoton: ma35d1: fix ma35d1_clk_pll_determine_rate logic", " - clk: hisilicon: reset: Use devm_kzalloc to initialize", " hisi_reset_controller", " - ARM: imx: fix device_node refcount leak in imx_src_init()", " - ARM: imx: fix device_node refcount leaks in imx7_src_init()", " - clk: imx: scu: drop redundant init.ops variable assignment", " - mm/mm_init: fix incorrect node_spanned_pages", " - perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails", " - pinctrl: bcm2835: Don't remove an unregistered GPIO chip", " - riscv: kexec_file: Split the loading of kernel and others", " - riscv: kexec_file: Fix crashk_low_res not exclude bug", " - media: keymaps: Remove obsolete RC_MAP_RC5_TV keymap define", " - media: keymaps: Remove obsolete RC_MAP_HAUPPAUGE_NEW keymap define", " - perf test: Update all metrics test like metricgroups test", " - perf test stat_all_metrics: Ensure missing events fail test", " - perf tests metrics: Permission related fixes", " - perf test metrics: Update all metrics for possibly failing default", " metrics", " - perf test all metrics: Fully ignore Default metric failures", " - perf test: Do not skip when some metrics tests succeeded", " - perf tests: Skip metrics validation if system-wide recording lacks", " permission", " - perf test: Use sqrtloop workload to test bperf event", " - perf test: Fix perf stat --bpf-counters on hybrid machines", " - perf tests: Fix flakiness in BPF counters test on hybrid systems", " - perf test brstack: Speed up running test by using tr -s instead of xargs", " - perf tests: Harden branch stack sampling test", " - perf test: Refactor brstack test", " - perf test: Add syscall and address tests to brstack test", " - perf test: Extend branch stack sampling test for Arm64 BRBE", " - perf test: Fixes for check branch stack sampling", " - perf tests: Fix flakiness in branch stack sampling tests", " - regulator: tps6594-regulator: Constify struct tps6594_regulator_irq_type", " - regulator: tps6594-regulator: remove interrupt_count", " - regulator: tps6594-regulator: remove hardcoded buck config", " - regulator: tps6594-regulator: refactor variant descriptions", " - regulator: tps6594: Fix device node reference leaks in multiphase loop", " - tools/bpf/bpftool: Reset vmlinux BTF after map commands", " - tools/bpf/bpftool: Reset vmlinux BTF after struct_ops commands", " - selftests/bpf: Systematically add SO_REUSEADDR in start_server_addr", " - selftests/bpf: Mask socket type flags in mptcpify prog", " - mm: add build-time option for hotplug memory default online type", " - [Config] Rename hotplug config: remove MEMORY_HOTPLUG_DEFAULT_ONLINE,", " add MHP_DEFAULT_ONLINE_TYPE_*", " - mm: convert memory block states (MEM_*) macros to enum", " - mm: change type of state in struct memory_block", " - mm: name the anonymous MMOP enum as enum mmop", " - dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation", " failure", " - dmaengine: hisilicon: Return -ENOMEM on dynamic memory allocation in", " probe", " - soundwire: qcom: Fix port exhaustion check in stream_alloc_ports", " - iio: orientation: hid-sensor-rotation: Avoid race between callback setup", " and device exposure", " - selftests/rseq: Replace glibc-specific __GNUC_PREREQ with portable check", " - wifi: rtw89: fix HE extended capability length check", " - perf cs-etm: Queue context packets for frontend", " - perf cs-etm: Fix thread leaks on trace queue init failure", " - perf/x86/amd/uncore: Add group validation", " - crypto: atmel-ecc - replace min_t with min", " - crypto: atmel-ecc - clean up and improve ECDH comments", " - nvmet-rdma: factor out response resource cleanup", " - bus: ti-sysc: Fix /chosen node reference leak", " - PM: sleep: Fix off-by-one in wakelocks number limit check", " - arm64: dts: qcom: sm7225-fairphone-fp4: Fix address in fb node name", " - bus: qcom-ebi2: Simplify with scoped for each OF child loop", " - bus: qcom-ebi2: Fix clock leak on probe failure", " - staging: greybus: audio: correct sscanf() return value check", " - staging: sm750fb: gate dualview dataflow using g_dualview", " - staging: sm750fb: Add missing Kconfig dependency", " - greybus: audio: bound the topology section sizes against the fetched", " size", " - staging: fbtft: Use sysfs_emit_at() to print to sysfs file", " - staging: octeon: add missing tasklet_kill in cvm_oct_tx_shutdown", " - staging: octeon: fix free_irq dev_id mismatch in cvm_oct_rx_shutdown", " - staging: octeon: ethernet-mem: replace pr_warn with dev_warn in free", " functions", " - staging: octeon: replace pr_warn with dev_warn in fill and rx paths", " - staging: octeon: add missing napi_disable in cvm_oct_rx_shutdown", " - staging: rtl8723bs: fix mismatched free of HalData in", " rtw_sdio_if1_init()", " - ALSA: via82xx: Remove unreachable branch in snd_via686_pcm_pointer()", " - selftests/bpf: Fix memory leak in msg_alloc_iov error path", " - selftests/bpf: Fix memory leak in msg_alloc_iov", " - selftests/lsm: Fix memory leak in attr_lsm_count", " - irqchip/gic-v3-its: Fix memleak in its_probe_one()", " - irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()", " - selftests: timers: leap-a-day: Fix -w option and update usage comment", " - clocksource: Unregister subsystem on device registration failure", " - y2038: uapi: Use 64-bit __kernel_old_timespec::tv_nsec on x32", " - timekeeping: Account for monotonicity adjustment in ntp_error", " - clk: qcom: gdsc: propagate gdsc_check_status() errors from", " gdsc_poll_status", " - clk: qcom: gdsc: propagate gdsc_enable() failure for ALWAYS_ON domains", " - arm64: dts: qcom: sc8180x-primus: Rename regulator nodes", " - arm64: dts: qcom: sc8180x-pmics: Add second PMC8180 GPIO", " - arm64: dts: qcom: sc8180x-primus: Describe the display power net", " - arm64: dts: qcom: sc8180x-lenovo-flex-5g: Rename regulator nodes", " - arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power net", " - perf data convert json: Fix trace_seq memory leak in", " process_sample_event()", " - usb: typec: ucsi: unregister debugfs entries on teardown", " - perf dso: Fix kallsyms DSO detection with fallback logic", " - efi: fix stale reference to efi_recover_from_page_fault()", " - iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX", " - iommu/msm: Return -ENOMEM on memory allocation failure in probe", " - iommu/amd: Prevent SB IOAPIC from overriding IVRS validation errors", " - iommu/amd: Add support for Hygon family 18h model 4h IOAPIC", " - iommu/amd: Fix false positive in SB IOAPIC IVRS validation", " - leds: pca9532: Fix inverted GPIO output polarity", " - platform/x86: lg-laptop: Drop debug-only ACPI notify handler", " - platform/x86: lg-laptop: Convert ACPI driver to a platform one", " - hwspinlock: propagate errno when registering single lock", " - serial: ma35d1: Fix OF node reference leaks in console init", " - USB: make single lock for all usb dynamic id lists", " - USB: make to_usb_driver() use container_of_const()", " - usb: mtu3: allow system suspend during active gadget connection", " - usb: renesas_usbhs: Fix power-off ordering on unbind", " - drm/panel: samsung-s6d16d0: Power off on prepare failure", " - perf metricgroup: Fix metric expression copy leaks", " - soc: qcom: rpmh-rsc: manage PM notifiers with devres", " - bus: qcom-ebi2: use managed resources for clocks and children", " - iio: accel: dmard09: Implement IIO_CHAN_INFO_SCALE", " - hwrng: ks-sa - Fix runtime PM cleanup on registration failure", " - ALSA: hpi: Check transport errors during HPI6000 adapter initialization", " - pmdomain: bcm: bcm2835: handle genpd provider registration errors", " - misc: rtsx_usb: avoid USB I/O in runtime autosuspend", " - RDMA/hfi1: Stop flushing the global IB workqueue", " - RDMA/hfi1: Initialize debugfs after probe completes", " - ASoC: apple: mca: increase SERDES reset delay", " - iommufd: Reorder include files", " - iommufd/selftest: Avoid selftest dirty bitmap size wrap", " - rpmsg: glink: remove duplicate code for rpmsg device remove", " - cxl/memdev: Fix firmware upload exact-fit handling", " - cxl/pci: Honor -EPROBE_DEFER from component register setup", " - fs/ntfs3: Add more checks in mi_enum_attr (part 2)", " - fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list", " - wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate", " - firmware: arm_scmi: Use dev_err_probe to bail out", " - firmware: arm_scmi: Avoid non-constant printk format strings", " - firmware: arm_scmi: Use channel ID for transport teardown", " - firmware: arm_scmi: Protect device request lookup with RCU", " - libnvdimm/labels: Bound the on-media label size before the shift", " - cpufreq: spear: Fix an IS_ERR() vs NULL bug in spear1340_set_cpu_rate()", " - PCI: xgene: Drop XGENE_PCIE_IP_VER_UNKN", " - PCI: xgene: Drop unnecessary OF node reference", " - media: i2c: rdacm21: Fix missing media_entity_cleanup()", " - drm/amd/display: Remove unused-but-set variable hubp from", " - cpufreq: intel_pstate: Fix setting minimum P-state at init time", " - cpufreq: schedutil: Fix self-contradictory comment in", " sugov_iowait_apply()", " - remoteproc: qcom: Fix glink->node reference leak in", " qcom_add_glink_subdev", " - arm64: dts: qcom: msm8996-xiaomi-gemini: Fix up ti,drv2604 enable GPIO", " - arm64: dts: qcom: sm8250: sort out Iris power domains", " - arm64: dts: qcom: sm8250: correct frequencies in the Iris OPP table", " - perf jevents: Add more components to the metric sorting order", " - wifi: iwlwifi: mei: pass correct argument to function", " - gpu: host1x: Fix offset calculation in trace_write_gather", " - drm/msm/a6xx: Fix stale rpmh votes after suspend", " - crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping", " - ACPI: processor: idle: Expand _LPI package sanity checks", " - tty: hvc: restrict HVC_DCC to ARMv6+ and ARM64", " - accessibility: speakup: Fix incorrect string length computation in", " report_char_chartab_status()", " - misc: rtsx: add missing write register handling", " - cacheinfo: don't propagate DT/ACPI error when arch supplies info (arm64)", " - ppdev: prevent overflow when setting port timeout", " - char: xilinx_hwicap: unregister class on init errors", " - perf ui hists: Fix uninitialized stack memory free on pstack allocation", " failure", " - driver core: soc: Unregister bus on early device registration failure", " - drm/msm/a6xx: Fix RBBM_CLOCK_CNTL3_TP0 value in a730_hwcg", " - dmaengine: dw-edma: Clear stale requests on termination", " - phy: starfive: Fix runtime PM cleanup in JH7110 DPHY RX probe", " - arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to", " nand_all_pins", " - arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for", " PCIe", " - RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters", " - kcsan: avoid unintended access checking in NMIs", " - selftests/bpf: Silence array bounds warning in global_map_resize", " - ACPI: EC: Avoid _REG disconnect on GPIO IRQ defer", " - ext4: fix circular lock dependency in ext4_ext_migrate", " - ext4: skip extra isize expansion during mount to prevent deadlock", " - libbpf: Search /lib64 and /lib in resolve_full_path()", " - ACPI: battery: Adjust charging status validation check", " - RDMA/srpt: Pass the mapped task attribute to target_init_cmd()", " - PCI: j721e: Fix incorrect max_lanes for J7200", " - RDMA/restrack: Fix typos in the comments", " - RDMA/core: Add rdma_restrack_begin/abort/commit_del() operations", " - RDMA/core: Add driver APIs pre_destroy_cq() and post_destroy_cq()", " - iommu/qcom: Remove sysfs device on probe failure path", " - iommu/qcom: Fix inverted fault report check in qcom_iommu_fault()", " - wifi: ath12k: Correctly copy the hint BSSID in WMI scan request", " - wifi: ath11k: Correctly copy the hint BSSID in WMI scan request", " - ARM: dts: allwinner: a10: Fix PMU interrupt", " - ACPI: CPPC: Add IS_OPTIONAL_CPC_REG macro to judge if a cpc_reg is", " optional", " - ACPI: CPPC: Optimize cppc_get_perf()", " - ACPI: CPPC: Rename cppc_get_perf() to cppc_get_reg_val()", " - ACPI: CPPC: Add cppc_set_reg_val()", " - ACPI: CPPC: Refactor register value get and set ABIs", " - ACPI: CPPC: Modify cppc_get_auto_sel_caps() to cppc_get_auto_sel()", " - cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory", " systems", " - firmware: arm_scmi: Roll back partial protocol table registration", " - perf cs-etm: Flush thread stacks after decoder reset", " - perf cs-etm: Avoid truncating AUX buffer sizes to int", " - RDMA/erdma: Probe the erdma RoCEv2 device", " - RDMA/erdma: Add GID table management interfaces", " - RDMA/erdma: Add the erdma_query_pkey() interface", " - RDMA/erdma: Add address handle implementation", " - RDMA/erdma: Add erdma_modify_qp_rocev2() interface", " - RDMA/erdma: Refactor the code of the modify_qp interface", " - RDMA/erdma: Add the query_qp command to the cmdq", " - RDMA/erdma: Fix incorrect response returned from query_qp", " - RDMA/erdma: Support non-sleeping erdma_post_cmd_wait()", " - PM: hibernate: Fix memory leak in snapshot_write_next() error path", " - leds: pca9532: Fix phantom device registration on missing hardware", " - drm/tve200: add OF module alias for autoloading", " - netfilter: nf_nat_sip: rewind offset when NAT shrinks the packet", " - arm64: dts: rockchip: Fix Gru WLAN sideband interrupt", " - ARM: lpc32xx: only run SoC init on LPC32xx hardware", " - selftests/bpf: Fix incorrect error checking for pthread_create", " - selftests/bpf: Fix memory leak on subtest_states reallocation", " - pinctrl: mediatek: Add EINT support for multiple addresses", " - pinctrl: mediatek: Fix the invalid conditions", " - pinctrl: mediatek: eint: Fix invalid pointer dereference for v1", " platforms", " - tools/build: Add bpftool-skeletons feature test", " - tools/build: Allow versioning of all LLVM tools defined in", " Makefile.include", " - power: supply: sbs-battery: Use a per-device serial number buffer", " - crypto: keembay - publish OF module alias for OCS AES/SM4", " - spi: bitbang: Follow renaming of SPI \"master\" to \"controller\"", " - spi: ppc4xx: Fix fallout from rename in struct spi_bitbang", " - w1: ds2482: Fix signedness bug in ds2482_w1_triplet()", " - remoteproc: core: Drop redundant initialization of 'ret' in", " rproc_shutdown()", " - remoteproc: Allow shutdown of crashed processors", " - remoteproc: core: Attach rproc asynchronously in rproc_add() path via", " schedule_work()", " - staging: rtl8723bs: use kfree_sensitive() for key material", " - RDMA/efa: Fix PBL chunk length computation", " - arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix", " - clk: tegra: tegra124-emc: put EMC node on register failure", " - clk: palmas: Manage external-control prepare with devm", " - clk/x86: pmc_atom: add kasprintf return value check", " - clk: mediatek: mt8135: Fix inverted gate control for devapc_ck", " - clk: rockchip: Fix the fractional part denominator on RK3588/RK3576 PLLs", " - scsi: smartpqi: Fix AIO retry marker cleared by SCSI core between", " dispatches.", " - RDMA/mlx5: Send cong param changes to the resolved port mdev", " - platform/chrome: cros_ec_debugfs: Clean up console log on probe failure", " - bus: mhi: host: Flush the posted write after writing to", " MHI_SOC_RESET_REQ_OFFSET", " - md/raid5: protect bitmap batch counters aka seq_flush/seq_write", " consistency", " - md/raid5-ppl: fix use-after-free in ppl_do_flush()", " - md: ensure resync is prioritized over recovery", " - md: allow removing faulty rdev during resync", " - md: rename recovery_cp to resync_offset", " - md: add a new recovery_flag MD_RECOVERY_LAZY_RECOVER", " - md: add a new helper rdev_has_badblock()", " - md/raid5: protect lockless recovery_offset accesses during reshape", " - tools/nolibc/powerpc: mark ctr and xer as clobbered by system call", " - selftests/zram: fix kernel_gte() for POSIX sh", " - slab: simplify init_kmem_cache_nodes() error handling", " - slab: Make slub local_(try)lock more precise for LOCKDEP", " - rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs", " - arm64: dts: qcom: msm8998: Don't pull-up I2C pins by default in sleep", " - arm64: dts: qcom: sdm632-motorola-ocean: Fix LED default trigger", " property", " - arm64: dts: qcom: qcs404: Fix DTBS Check errors in usb controller nodes", " - clk: qcom: gcc-qcm2290: don't park QUP RCGs upon registration", " - arm64: dts: qcom: sc8280xp-crd: Fix the pin index for misc_3p3_reg_en", " - dt-bindings: interrupt-controller: arm,gic: add ESPI and EPPI specifiers", " - firmware: qcom_scm: Add API to get waitqueue IRQ info", " - firmware: qcom: scm: Remove redundant scm argument from", " qcom_scm_waitq_wakeup()", " - firmware: qcom_scm: Support multiple waitq contexts", " - firmware: qcom: scm: add trace events for the SMC call interface", " - firmware: qcom: scm: instrument SMC call path with tracepoints", " - arm64: dts: qcom: sm8250-xiaomi-elish: correct the board ID", " - arm64: dts: qcom: sc8180x: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sdm845: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8150: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8250: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8350: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8450: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8550: Fix the PCIe iommu-map entries", " - arm64: dts: qcom: sm8650: add OPP table support to PCIe", " - arm64: dts: qcom: sm8650: Fix the PCIe iommu-map entries", " - clk: qcom: Return expected ENOMEM error on dynamic allocation failure", " - md: remove unused mddev argument from export_rdev", " - md: skip redundant raid_disks update when value is unchanged", " - i3c: master: Fix device_register() error path", " - md: merge mddev has_superblock into mddev_flags", " - md: merge mddev faillast_dev into mddev_flags", " - md: merge mddev serialize_policy into mddev_flags", " - locking/lockdep: Fix NULL pointer dereference in __lock_set_class()", " - misc: vmc_vmci: Fix potential memory leak in vmci_event_subscribe()", " - mm/treewide: replace pmd_large() with pmd_leaf()", " - fanotify: report full event length for FIONREAD", " - wifi: mt76: mt7915: fix net_fill_forward_path for non-DBDC mt7986", " - wifi: mt76: mt7925: fix msg len mismatch between driver and firmware", " - wifi: mt76: mt7996: fix capability of EHT-MCS 15 in MRU", " - wifi: mt76: mt7996: set MT76_MCU_RESET before waking MCU waiters on full", " reset", " - wifi: mt76: mt7996: don't report a zero TX bitrate", " - wifi: mt76: mt7915: write RX header translation bit to the correct", " register", " - wifi: mt76: mt7915: poll the correct SLP CTRL register for the second", " adie", " - wifi: mt76: check txfree done event on the WED hw path", " - wifi: mt76: mt7915: use little-endian for bss_info_ra wire fields", " - wifi: mt76: only consume the WO drop bit on WED v2 devices", " - perf: arm_spe: Make wakeup range check overflow safe", " - drm/msm/dpu: Drop sneaky dev_pm_opp_set_rate(0)", " - perf machine: Fix NULL parent dereference in fork event processing", " - perf machine: Guard against NULL strlist in machines__findnew()", " - perf machine: Use snprintf() for guestmount path construction", " - perf machine: Check snprintf truncation in machines__findnew()", " - perf machine: Don't abort guest map creation on first inaccessible dir", " - perf machine: Reset errno before strtol in guest kernel map creation", " - perf machine: Free scandir entries in guest kernel map creation", " - perf machine: Check snprintf truncation for guest kallsyms path", " - wifi: mt76: mt7996: fix reg addr remap when addr is 0", " - wifi: mt76: mt7915: fix chainmask handling for non-dbdc phys on band 1", " - wifi: mt76: mt7915: report RX chain signal for all RX paths", " - wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band", " - wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be", " minimum", " - iommu/arm-smmu-v3: Convert to use atomic poll timeout", " - perf/cxlpmu: Fix 64-bit write to 32-bit HDM filter register", " - wifi: mac80211: send TWT teardown to peer after setup TX failure", " - wifi: zd1211rw: reject secondary interfaces to prevent conflicts", " - wifi: mac80211: skip unused probe response countdown offsets", " - firmware: google: Add bounds checks in coreboot_table_populate()", " - powerpc/smp: add NULL guard for cause_ipi in smp_muxed_ipi_message_pass", " - powerpc/irq: Fix missing r2 clobber in PCREL inline assembly", " - MIPS: ptrace: Fix syscall skipping via PTRACE_SYSCALL", " - serial: amba-pl011: unprepare console clock on unregister", " - HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver", " - HID: i2c-hid: Fix \"(null)\" output when reading report descriptor fails", " - HID: i2c-hid: goodix: Disable VDD on VDDIO enable failure", " - HID: lg4ff: validate report length before fixed offsets", " - perf thread-stack: Fix heap buffer overflow on branch stack wrap copy", " - perf auxtrace: Fix queue grow overflow and old array leak", " - perf intel-pt: Fix off-by-one in auxtrace_info minimum size check", " - perf intel-bts: Fix off-by-one in auxtrace_info minimum size check", " - iio: light: tsl2772: fix ALS calibscale readback", " - iio: light: isl29028: return zero in write_raw() on success", " - iio: light: tsl2583: return zero in write_raw() on success", " - block/blk-stat: drain per-cpu callback stats over possible CPUs", " - block/blk-iocost: collect per-cpu latency stats over possible CPUs", " - block/kyber-iosched: flush per-cpu latency buckets over possible CPUs", " - ublk: check for ublk_unmap_io() returning 0", " - o2hb_region_dev_store(): avoid goto around fdget()/fdput()", " - lib/string: fix memchr_inv() for large ranges", " - pps: don't try to wait for negative timeouts in PPS_FETCH", " - pps: clients: gpio: Bypass edge's direction check when not needed", " - pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded", " handler", " - pps-gpio: remove dead capture_clear code", " - arm64: dts: qcom: agatti: Add missing CX power domain to DISPCC", " - remoteproc: Move resource table data structure to its own header", " - remoteproc: use rsc_table_for_each_entry() in rproc_handle_resources()", " - selftests/mm: add new test cases to the migration test", " - ksm_tests: skip hugepage test when Transparent Hugepages are disabled", " - selftests/mm: ksm_tests: use kselftest framework", " - selftests/mm: fix ksm NUMA merge test for systems with memoryless NUMA", " nodes", " - selftests/mm: fix ternary operator precedence in ksm_tests", " - arm64: dts: qcom: sm7225-fairphone-fp4: Fix swapped USB QMP PHY vdda-", " phy/vdda-pll supplies", " - scripts/tags.sh: Prevent binary files appearing in cscope.files", " - modpost: prevent leak when early return no suffix .o in read_symbols()", " - drm/sun4i: vi scaler: Fix coefficient selection", " - drm/sun4i: tcon: Set output mux for DSI and LVDS", " - drm/sun4i: hdmi: Don't leak sync polarity bits into packet control", " - drm/sun4i: tcon: Drop remote endpoint reference", " - drm/sun4i: dw-hdmi: Drop TCON TOP port reference", " - drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHz", " - module: replace use of system_wq with system_dfl_wq", " - module: use strscpy() to copy module names in stats and dup tracking", " - module/dups: Inform duplicate requests about the result directly", " - RDMA/erdma: restrict the driver to little-endian systems", " - [Config] Set INFINIBAND_ERDMA to not-applicable on s390x", " - wifi: mac80211: skip default WMM setup for AP_VLAN links", " - arm64: hibernate: mask DAIF before restoring hibernated kernel", " - mfd: rave-sp: validate received frame payload lengths", " - mfd: iqs62x: Reject zero-length firmware records", " - drm/amdgpu/gfx6: Fixup emit_cntxcntl()", " - ext4: fix spurious message about orphan cleanup on RO fs", " - arm64: dts: ti: k3-am64: Fix MDIO clock reference for ICSSG0 node", " - phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table", " - perf trace-event: Fix buffer overflow in read_string()", " - drm/amdgpu/gfx6: Fixup emitting SWITCH_BUFFER packets", " - pinctrl: rockchip: Reset the pin count when recalculating SoC data", " - soc: fsl: qe: check platform_driver_register() in qe_ic_of_init()", " - phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()", " - phy: qcom: sgmii-eth: vote for both voltage rails with correct current", " loads", " - md: avoid stale clone I/O accounting timestamps", " - coresight: etm4x: fix wrong check of etm4x_sspcicrn_present()", " - coresight: Change syncfreq to be a u8", " - coresight: etm4x: fix leaked trace id", " - regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling", " - ACPI: video: Release PCI device reference after lookup", " - perf/x86/intel/pt: Factor out pt_config_enable()", " - perf/x86/intel/pt: Use bitwise access for PERF_HES_STOPPED", " - perf/x86/intel/pt: Fix stop/start with no update", " - sched/fair: Check CPU capacity before comparing group types during load", " balance", " - Bluetooth: btqca: Fix qca_set_bdaddr() waiting for wrong HCI event", " - Bluetooth: btusb: Fix BD_ADDR byte order in btusb_set_bdaddr_wcn6855()", " - Bluetooth: btusb: refactor endpoint lookup", " - Bluetooth: btusb: Record matched usb_device_id into btusb_data", " - Bluetooth: btusb: QCA: Fix populating devcoredump fields on unenabled", " devices", " - perf trace-event: Fix integer truncation in do_read() and skip()", " - scsi: sd: Fix sd_done() sense handling condition", " - Bluetooth: btintel: Fix diagnostics event detection", " - mmc: sdio: add MediaTek MT7902 SDIO device ID", " - Bluetooth: btmtk: add MT7902 MCU support", " - Bluetooth: btmtk: add MT7902 SDIO support", " - Bluetooth: btmtksdio: fix usage_count leak when autosuspend_delay is", " negative", " - cgroup: Add bpf prog revisions to struct cgroup_bpf", " - bpf: Implement mprog API on top of existing cgroup progs", " - iio: light: gp2ap002: re-enable irq if runtime suspend fails", " - riscv: cpufeature: Clarify ISA spec version for canonical order", " - arm64: dts: turris-mox: fix usb3 phys", " - ARM: dts: helios4: add vcc-supply to EEPROM", " - ARM: dts: helios4: add vcc-supply to GPIO expander", " - ARM: dts: helios4: add SATA regulator supplies", " - perf stat: Fix evsel_list leak in cmd_stat", " - perf synthetic-events: Fix uninitialized pthread_join", " - perf test: Introduce workloads__for_each()", " - perf test: Add a signal handler around running a test", " - perf test: Add a signal handler to kill forked child processes", " - perf test: Rename functions and variables for better clarity", " - perf test: Send list output to stdout rather than stderr", " - perf test: Support dynamic test suites with setup callback and private", " data", " - perf test: Fix skiplist leak in cmd_test", " - perf python: Remove python 2 scripting support", " - perf python: Add support for 'struct perf_counts_values' to return", " counter data", " - perf python: Check counts_values size in set_values", " - perf synthetic-events: Fix divide by zero in", " perf_event__synthesize_threads", " - fbdev: tdfxfb: fix PCI enable cleanup with pcim_enable_device()", " - iommu/vt-d: Fix UCTP context table slot when copying root entries", " - m68k: Fix backtraces for non-running tasks", " - arm64: Disable KCSAN instrumentation in delay.o", " - powerpc/configs: enable CONFIG_RAS to fix EDAC support", " - phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs", " - phy: qualcomm: qmp-combo: add support for SAR2130P", " - phy: qcom: qmp-combo: Add new PHY sequences for SM8750", " - phy: qcom-qmp-combo: Use regulator_bulk_data with init_load_uA for", " regulator setup", " - phy: qualcomm: Update the QMP clamp register for V6", " - phy: qualcomm: qmp-combo: Update QMP PHY with Glymur settings", " - phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur", " platforms", " - phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy", " - spi: sprd-adi: Fix probe succeeding without registering the controller", " - ASoC: qcom: q6apm: keep the graph start count in sync with the DSP", " - nvme: add reservation command's defines", " - nvme: introduce change ptpl and iekey definition", " - nvme: Add the DHCHAP maximum HD IDs", " - nvme-apple: Don't set a DMA direction for commands without a data", " transfer", " - nvme-apple: Never set the opcode in the NVMMU TCB", " - nvme: apple: Add Apple A11 support", " - nvme-apple: Drop the PRP null check chicken bit", " - nvme: reject passthrough of driver-managed Set Features", " - nfc: digital: Do not dump a NULL response in command completion", " - dmaengine: qcom-bam-dma: fix autosuspend cleanup during removal", " - ice: clear the default forwarding VSI rule when releasing a VSI", " - ASoC: pxa: Use devm_clk_get_optional() for extclk clock", " - ASoC: fsl-asoc-card: defer probe when the CPU DAI device is not ready", " - UBI: Preserve torture flag when rescheduling failed erasures", " - UBI: fastmap: Pass to_be_tortured when reusing old fastmap PEBs", " - mtd: ubi: Release device reference on busy detach", " - UBI: fix two issues in the ubi.mtd MODULE_PARM_DESC", " - firewire: core: add common inline functions to serialize/deserialize", " asynchronous packet header", " - firewire: obsolete usage of *-objs in Makefile for KUnit test", " - firewire: core: add enumerator of self ID sequences and its KUnit test", " - firewire: ohci: add static inline functions to deserialize for Self-ID", " DMA operation", " - firewire: core: add KUnit test skeleton for node tree", " - firewire: core: add KUnit tests for successful tree building", " - firewire: core: add KUnit tests for failure of tree building", " - firewire: core: consolidate port counting in build_tree()", " - firewire: core: validate parent port count before allocating nodes in", " build_tree()", " - PCI/ASPM: Use pcie_capability_clear_and_set_word() for ASPM", " disable/restore", " - super: fix dying superblock warning messages", " - kunit: tool: fix _list_tests filtering wrong variable when list has TAP", " prefix", " - selftests/bpf: vmtest.sh: Preserve command quoting when running in the", " VM", " - spi: img-spfi: don't disable runtime PM on DMA deferred probe", " - PCI/ASPM: Cache L0s/L1 Supported so advertised link states can be", " overridden", " - PCI/ASPM: Disable/restore ASPM on every function for multi-function", " devices", " - power: supply: bd99954: Drop bad register fields", " - power: supply: bq27xxx: bq27520g4: fix REG_TTES address", " - power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy address", " - power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy address", " - xenbus: Unregister reboot notifier on init failure", " - clocksource/drivers/clps711x: Do not unmap clocksource MMIO", " - clocksource/drivers/armada: Unwind timer clock on init failure", " - ALSA: seq: midi: Optimize event_input locking with RCU", " - cgroup/cpuset: Fix spelling errors in file kernel/cgroup/cpuset.c", " - cgroup/cpuset: Remove remote_partition_check() & make", " update_cpumasks_hier() handle remote partition", " - selftest/cgroup: Update test_cpuset_prs.sh to use | as effective CPUs", " and state separator", " - selftest/cgroup: Clean up and restructure test_cpuset_prs.sh", " - selftests/cgroup: Preserve CPU hotplug write errors", " - x86/pkeys: Fix pkey_alloc() return value when pkeys are not supported", " - bpftool: Fix double close in map dump", " - ocfs2: fix circular locking dependency in ocfs2_init_acl()", " - selftests/bpf: Fix for veristat file/prog filters processing", " - scsi: ufs: core: Remove redundant host_lock calls around UTMRLDBR", " - scsi: ufs: core: Set task state before io_schedule_timeout()", " - tracing: Remove \"__attribute__()\" from the type field of event format", " - tracing: Have trace_event_update_all() only handle module that is", " loading", " - HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU", " - riscv, bpf: Fix missing sign-ext for signed 1-byte and 2-byte kfunc args", " - ring-buffer: Remove trace_buffer::cpus", " - bpf: Fix pending_pos walk on 32-bit ring position wrap", " - crypto: hisilicon/sec2 - fix CCM algorithm long packet failure", " - crypto: lskcipher - propagate errors from unaligned crypt", " - perf dso: Guard close() against invalid fd in", " dso__decompress_kmodule_path()", " - perf dso: Use stored fd error instead of stale errno in file_read() and", " file_size()", " - perf dso: Guard against cache underflow on short reads in", " dso_cache__memcpy()", " - mailbox: rockchip: disable pclk on probe failure and unbind", " - mailbox: pcc: Always map the shared memory communication address", " - mailbox/pcc: support mailbox management of the shared buffer", " - Revert \"mailbox/pcc: support mailbox management of the shared buffer\"", " - mailbox: pcc: Fix command timeout due to missed interrupt", " - ublk: reject non-power-of-2 zone sizes in SET_PARAMS", " - hwmon: (emc1403) Rely on subsystem locking", " - hwmon: (emc1403) Drop hysteresis for low limit temperature", " - ksmbd: do not advertise unimplemented CA support", " - smb/server: preserve error status in smb2_handle_negotiate()", " - erofs: convert z_erofs_bind_cache() to folios", " - erofs: support unaligned encoded data", " - erofs: fix unused pcluster_pools for higher page sizes", " - ksmbd: disconnect on SMB3 decryption failure", " - nfs: replace atomic bitops sequence with clear_and_wake_up_bit helper", " - nfs: refactor pNFS functions using clear_and_wake_up_bit", " - clk: ti: use kcalloc() instead of kzalloc()", " - clk: ti: mux: resolve parent clocks by DT index, not by name", " - octeontx2-af: initialize lmac_bmap in rvu_mcs_set_lmac_bmap()", " - drm/xe: tests: fix error message in xe_migrate_sanity_test()", " - net: dsa: b53: fix error propagation from b53_fdb_dump()", " - pppox: drain queued packets on channel handoff", " - net: hsr: free learned nodes on device setup failure", " - f2fs: fix to parse temperature correctly in f2fs_get_segment_temp()", " - f2fs:Fix incomplete search range in f2fs_get_victim when", " f2fs_need_rand_seg is enabled", " - f2fs: cleanup w/ f2fs_need_rand_{blk, seg, seg_blk}", " - f2fs: fix to avoid pinfile fragment on fragment:{block, segment} mode", " - net: dsa: mv88e6xxx: Fix PCS link check on CMODE read error", " - tls: fix RX desync on overlapping skbs", " - net: bridge: vlan: fix inverted default vlan notification", " - fuse: support folios in struct fuse_args_pages and fuse_copy_pages()", " - fuse: convert readdir to use folios", " - fuse: check attributes staleness on fuse_iget()", " - ALSA: hda: Fix connection list comparison in proc output", " - vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()", " - 8139cp: fix Rx and Tx not being disabled in cp_suspend", " - net/smc: hash socket only after full initialisation in smc_sk_init()", " - platform/x86: dell-wmi-sysman: Fix instance ID bounds", " - vsock: avoid timeout for non-blocking accept() with empty backlog", " - vsock: use sock_error() to consume sk_err after a failed connect", " - mlxbf-bootctl: fix the build error with FIELD_PREP()", " - bonding: initialize err for empty target lists", " - i3c: mipi-i3c-hci: Quieten initialization messages", " - i3c: mipi-i3c-hci: Switch PIO data allocation to devm_kzalloc()", " - i3c: mipi-i3c-hci: Refactor PIO register initialization", " - i3c: mipi-i3c-hci: Fix missing STAT_IBI_STATUS_THLD in PIO mode", " - virtio_balloon: disable indirect descriptors", " - rtc: zynqmp: Return optional clock lookup errors", " - i2c: ocores: Disable clock on failed resume", " - rtc: gamecube: check return value of devm_rtc_register_device()", " - prctl: fix PR_SET_MM_AUXV losing the forced AT_NULL terminator", " - clk: ti: Make sure clk_init_data is fully initialized", " - ALSA: core: Add scoped cleanup helper for card references", " - RDMA/ucma: Allow path records to exactly fit the output buffer", " - xsk: Get rid of xdp_buff_xsk::orig_addr", " - xsk: avoid double checking against rx queue being full", " - net/sched: add get_fill_size callbacks for actions missing them", " - net: thunderbolt: Count delivered packets in rx_packets and rx_bytes", " - forcedeth: stop the tx_timeout register dump past the requested window", " - net: ipa: balance runtime PM reference on remove error", " - net: add missing ref_tracker_dir_exit() to net_passive_dec()", " - net_sched: sch_fifo: implement lockless __fifo_dump()", " - nfs: move the nfs4_data_server_cache into struct nfs_net", " - rtc: pcf85363: Add error checking to regmap calls in probe()", " - scsi: qla2xxx: Fix an loop timeout test", " - erofs: Fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS default logic", " - s390: Add missing _TIF defines", " - s390: Add ARCH_HAS_PREEMPT_LAZY support", " - powerpc: Add preempt lazy support", " - mm: make DEBUG_WX depdendent on GENERIC_PTDUMP", " - mm: rename GENERIC_PTDUMP and PTDUMP_CORE", " - [Config] Rename ptdump configs: GENERIC_PTDUMP->ARCH_HAS_PTDUMP,", " PTDUMP_CORE->PTDUMP", " - mm/ptdump: split note_page() into level specific callbacks", " - arm64: ptdump: Make note_page_flush() range aware", " - Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereference", " - Bluetooth: btmtk: Mark all stub functions as inline", " - Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support", " - Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read()", " - Bluetooth: btmtk: Do not report success when subsys reset fails", " - Bluetooth: btmtk: Do not discard the subsystem reset timeout", " - Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX", " - octeontx2-af: Fix TL3/TL2 link config ENA clearing", " - cifs: fix clearing stats for fastest execution of each smb2 command", " - selftests/mm/cow: modify the incorrect checking parameters", " - selftests/mm: add helper for logging test start and results", " - selftests/mm: report unique test names for each cow test", " - selftests/mm: skip COW tmpfile cases when fallocate() is unsupported", " - maple_tree: catch race in mas_alloc_cyclic()", " - maple_tree: fix argument name in header", " - net_sched: act_skbmod: use RCU in tcf_skbmod_dump()", " - net/sched: sch_codel: clamp default mtu to avoid disabling CoDel", " - tpm: st33zp24: Validate locality read result", " - apparmor: Replace sprintf/strcpy with scnprintf/strscpy in", " aa_policy_init", " - apparmor: policy_int make sure list heads are initialized before fail", " path", " - ceph: revalidate ki_pos for O_APPEND writes after cap acquisition", " - samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-modify", " - net: ethernet: sun4i-emac: Fix IRQ error handling", " - net: wangxun: use BIT_ULL() to prevent shift overflow on 32-bit archs", " - net: stmmac: selftests: Pass the IP proto mask in the TC selftest", " - netfilter: xt_cgroup: Make it independent from net_cls", " - netfilter: xt_HL: add pr_fmt and checkentry validation", " - netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()", " - selftests: arm64: add hugetlb mte tests", " - selftests/arm64: Print missing MTE TAP headers", " - selftests/arm64: Treat KSM merge_across_nodes as optional", " - net: stmmac: selftests: Check multiple MMC counters", " - net: stmmac: dwmac1000: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwmac4: Account for the primary MAC address for UC", " filtering", " - net: stmmac: dwxgmac: Account for the primary MAC address for UC", " filtering", " - net: stmmac: selftests: Account for the UC filter list for filtering", " tests", " - platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL", " - pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()", " - pinctrl: mediatek: Fix new design debounce issue", " - pinctrl: mediatek: common-v1: Fix EINT breakage on older controllers", " - md: keep recovery_cp in mdp_superblock_s", " - slub: Don't call lockdep_unregister_key() for immature kmem_cache.", " - ACPI: processor: Update cpuidle driver check in __acpi_processor_start()", " - fscrypt: convert bh_get_inode_and_lblk_num to use a folio", " - fscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT", " - selftests/bpf: add verification for BPF_PROG_QUERY attr size boundaries", " - bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", " - phy: qcom: qmp-combo: Add missing PLL (VCO) configuration on SM8750", " - nvme-apple: Prevent shared tags across queues on Apple A11", " - nvme-apple: Reset q->sq_tail during queue init", " - cpuset: fix warning when disabling remote partition", " - erofs: fix managed cache race for unaligned extents", " - xsk: Fix offset calculation in unaligned mode", " - Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array", " - net/sched: fq: clamp quantum and initial_quantum in change path", " - kselftest/arm64: mte: Skip the hugetlb tests if MTE not supported on", " such mappings", " - kselftest/arm64: mte: Use the correct naming for tag check modes in", " check_hugetlb_options.c", " - md: add helper rdev_needs_recovery()", " - md: add a new enum type sync_action", " - md: add new helpers for sync_action", " - md: factor out helper to start reshape from action_store()", " - md: replace sysfs api sync_action with new helpers", " - md: fix sync_action incorrect display during resync", " - net_sched: act_ct: use RCU in tcf_ct_dump()", " - net_sched: act_ctinfo: use RCU in tcf_ctinfo_dump()", " - net_sched: act_skbedit: use RCU in tcf_skbedit_dump()", " - net_sched: act_vlan: use RCU in tcf_vlan_dump()", " - net_sched: act_tunnel_key: use RCU in tunnel_key_dump()", " - net_sched: add back BH safety to tcf_lock", " - tools/build: Use SYSTEM_BPFTOOL for system bpftool", " - pinctrl: mediatek: common-v1: Fix error checking in mtk_eint_init()", " - ACPI: processor: Add cpuidle driver check in", " acpi_processor_register_idle_driver()", " - Upstream stable to v6.6.157, v6.12.110", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90053", " - net/sched: sch_htb: limit htb_classify inner-class filter hops", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90054", " - tcp: fix corruption of urgent data on multi-segment retransmit", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90055", " - usb: atm: usbatm: fix invalid ci_range initialization", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90056", " - net: fec: only stop PTP if it was initialized", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90057", " - slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90058", " - net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90060", " - ALSA: control: Don't add invalid kcontrols to LED layer", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90062", " - netfilter: nf_tables: move hardware offload step after building the", " chain blob", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90063", " - virtio-net: Ensure that TCP packets don't overflow gso_segs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90066", " - samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-", " modify", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90067", " - libceph: validate banner payload length", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90068", " - ASoC: dapm: Fix off-by-one check on the second enum channel", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90070", " - tpm: st33zp24: Return zero on status read failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90071", " - net/sched: sch_teql: restore skb->dev on the slave failure path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90072", " - net/sched: sfq: clamp quantum to avoid signed overflow soft lockup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90073", " - net/sched: hhf: clamp quantum before hhf_change() to avoid overflow", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90074", " - net/sched: fq_pie: clamp default quantum to avoid signed overflow", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90075", " - net/sched: fq_codel: clamp default quantum and mtu", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90076", " - net/sched: fq: add overflow bounds to quantum and initial quantum", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90078", " - net/sched: act_skbmod: fix length calculations and avoid invalid header", " warnings", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90081", " - net/rds: use wq_has_sleeper() in rds_cong_map_updated()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89780", " - net: qualcomm: rmnet: restore skb->dev on deaggregated frames", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89789", " - gtp: add synchronize_net() in gtp_newlink() error path to prevent use-", " after-free", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90088", " - Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite", " loop", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90090", " - Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90091", " - Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90092", " - Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90101", " - bnxt_en: Fix call to hardware monitoring event handler", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90102", " - NFSv4/pnfs: key the data server cache on the NFS version", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90103", " - NFSv4.2: fix LAYOUTSTATS send buffer exhaustion", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90107", " - net/smc: free pending qentry in smc_llc_flow_stop() before memset", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90108", " - net/smc: free stashed qentry before overwrite in REQ_ADD_LINK to", " ADD_LINK transition", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90109", " - net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90110", " - inetpeer: randomize RB-tree node comparison using SipHash", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90112", " - net: qlcnic: validate unified ROM sections before loading", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90114", " - net: bridge: Reject descending VLAN tunnel ranges", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90115", " - xsk: fix NULL pointer dereference in __xsk_rcv()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90119", " - ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90122", " - clk: visconti: Make sure clk_init_data is fully initialized", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90124", " - irqchip/renesas-rzg2l: Fix loss of interrupt", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90125", " - smb: client: fix request buffer leak in smb2_new_read_req()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90126", " - rtc: pcf8563: fix clock provider leak on unbind", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90128", " - vdpa/mlx5: fix wrong list iterated in add_direct_chain error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90130", " - vdpa_sim: fix cleanup after worker creation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90135", " - net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90137", " - platform/x86: hp-bioscfg: fix password encoding bounds check", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90138", " - vsock: don't check the listener's sk_err in vsock_accept()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90139", " - fuse: check for NULL root inode in fuse_fill_super_submount", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89779", " - fs/ntfs3: validate ef->size covers the record's name and value", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89781", " - fs/ntfs3: fix out-of-bounds read in read_log_rec_buf()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90140", " - cuse: wait for pending RCU callbacks on module exit", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89776", " - vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90141", " - ipvs: fix integer overflow in ftp helper port/address parsing", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90143", " - net: kcm: Hold RCU read lock while running BPF parser", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90148", " - NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in", " nfs4_add_lease()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90150", " - pnfs/blocklayout: Fix device leaks on parse failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90151", " - NFSv4: remove callback IDR entry on client allocation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90152", " - smb/server: fix session leak in ksmbd_session_register()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90153", " - ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90157", " - bpf: Reject negative optlen in cgroup getsockopt hook", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90158", " - m68k: nfcon: Do not call console_is_registered() in nfcon_device()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90159", " - bpf: Disallow bpf_{g,s}etsockopt() in cgroup UNIX getname hooks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90160", " - lwt_bpf: Restore reserved headroom after xmit program", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90166", " - smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90169", " - ksmbd: free preauth sessions on connection teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90170", " - ksmbd: validate ipc response length before dereferencing its fields", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90175", " - smb: server: fix leak of ksmbd_ipc_login_request_ext() returned buffer", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90176", " - ksmbd: Do not skip lock checks for single-byte ranges", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90178", " - hwmon: (coretemp) Fix core_data leak on CPUs without PTS", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90180", " - block: mtip32xx: synchronize ioctls with device removal", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90184", " - null_blk: serialize configfs attribute updates with device setup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90185", " - null_blk: serialize configfs attribute stores with the lock", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90186", " - null_blk: reject per-device queue resize for shared tag set", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90187", " - null_blk: free zones array on device power-off", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90188", " - null_blk: free global tag_set on init error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90189", " - null_blk: register configfs subsystem after creating default devices", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90190", " - null_blk: use DEFINE_MUTEX for the file-scope mutex", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90194", " - ACPI: scan: fix bus ID cleanup on device_add() failures", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90196", " - ASoC: SOF: validate topology volume range before allocation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90198", " - ALSA: core: Fix use-after-free in snd_card_do_free()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90199", " - fs/ntfs3: reject out-of-range evcn in mi_enum_attr()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90200", " - fs/ntfs3: fix integer overflow in MFT cluster validation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90202", " - scsi: mpt3sas: Avoid freeing unallocated PCIe SGL buffers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90203", " - Squashfs: check block offset is not negative", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90207", " - ALSA: seq: midi: Serialize input teardown with event_input", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90209", " - s390/debug: Fix deadlock during unregister", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90213", " - firewire: core: fix memory leak in error path of build_tree()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90214", " - ASoC: xilinx: formatter_pcm: fix stream_data leak on open error", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90216", " - ubi: Fix rollback for explicit UBI device numbers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90218", " - RDMA/cma: Fix WARNING in res_to_rt", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90219", " - RDMA/cxgb4: Free debugfs on registration failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90220", " - ALSA: seq: Don't leak the extension cell pointer in the bounce payload", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90221", " - nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90222", " - nfc: pn533: hold a reference to the request skb during send_frame", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90223", " - nfc: llcp: bound SNL TLV parsing to the skb and add length checks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90224", " - nfc: nci: fix double completion race in nci_data_exchange_complete", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90225", " - nfc: llcp: read llcp_sock->local under the socket lock in getsockopt", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90226", " - nfc: llcp: avoid userspace overflow on invalid optlen", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90227", " - nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90228", " - nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90229", " - nvme-apple: Destroy the admin queue on removal", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90230", " - nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90235", " - sunrpc: xprtsock: annotate shared socket callbacks with", " READ_ONCE/WRITE_ONCE", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89784", " - SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90245", " - fbdev: kyro: Validate overlay viewport coordinates", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90248", " - net/sched: cls_api: fix teardown of an adopted proto on insert-race loss", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90249", " - iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90250", " - bpf, cgroup: Fix storage null-ptr-deref after replacing prog", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90251", " - Bluetooth: MSFT: validate evt_prefix_len against the response length", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90253", " - Bluetooth: MGMT: free the mesh send cancel command when it is cancelled", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90254", " - Bluetooth: hci_sync: free the advertising instance on the failure and", " cancel paths", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90255", " - Bluetooth: hci_conn: fix the SCO setup context lifetime", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90257", " - Bluetooth: virtio_bt: avoid OOB read of build info string", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90262", " - btrfs: retry verity reads for not-uptodate Merkle folios", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90274", " - coresight: etm4x: fix underflow for usage of (nrseqstate - 1)", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90275", " - md/raid1: don't set array_frozen in raid1_takeover()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90279", " - md/raid5: round bitmap stripes with sector division", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90280", " - phy: qcom: qmp-usb: Fix possible NULL-deref on early runtime suspend", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90281", " - phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime", " suspend", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90282", " - phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime", " suspend", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90283", " - hugetlbfs: release subpool on fill_super failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90284", " - firmware_loader: do not queue completed sysfs fallback requests", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90285", " - scsi: qla2xxx: Remove redundant VPD flash read in sysfs read path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90286", " - drm/amdgpu/gfx6: Use PFP on the compute queues too", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90287", " - phy: sunplus: fix error handling in sp_uphy_init()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90290", " - arm64: hibernate: Restore DAIF state on error", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90291", " - module/dups: Fix use-after-free in kmod_dup_req lifetime handling", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90292", " - RDMA/siw: Fix use-after-free in siw_accept()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90293", " - IB/isert: post the full-feature receive buffers after session", " registration", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90294", " - IB/isert: delay the final Login Response until the session is registered", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90295", " - cpufreq: imx6q: fix out-of-bounds write when probed more than once", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90296", " - cpufreq: imx6q: fix devres accumulation across driver rebind", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90297", " - drm/sun4i: crtc: Propagate layer initialization error", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90298", " - drm/sun4i: tcon: Drop TCON TOP device reference", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90302", " - ocfs2: synchronize heartbeat callbacks with o2net teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90303", " - ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user", " faults", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90307", " - RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90308", " - RDMA/erdma: Hold QP references for AE and CM processing", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90309", " - RDMA/erdma: Hold CQ references when processing EQ events", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90313", " - bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90314", " - remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90316", " - drm/omap: dsi: Do not copy isr table", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90318", " - fat: release buffer head after rebuilding parent", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90319", " - rapidio: clear mport->net when rio_add_net() fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90322", " - ocfs2/cluster: keep heartbeat local node stable", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90325", " - blk-cgroup: skip dying blkg in blkcg_activate_policy()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90327", " - phonet: pep: do not write beyond optlen in getsockopt", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90329", " - HID: synchronize input before cleaning up a failed probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90334", " - tty: clear cdev pointer after cdev_add() failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90341", " - firmware: coreboot: Validate table bounds", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90348", " - wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90352", " - wifi: mt76: mt7915: release hif2 reference on probe IRQ failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90353", " - wifi: mt76: mt7915: fix ext PHY use-after-free on register error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90354", " - wifi: mt76: mt7915: fix double hif2 init on the non-WED path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90357", " - wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90358", " - bpf, x86: Fix trampoline stack size for 128-bit arguments", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90360", " - regulator: core: use system_freezable_wq for init complete work", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90361", " - wifi: ath11k: fix leak in ath11k_service_ready_ext_event()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90362", " - drm/msm/dsi: Drop dev_pm_opp_set_rate(0)", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90364", " - ACPI: processor: Unregister cpufreq notifier on init failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90366", " - wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90368", " - wifi: mt76: mt7915: unwind state on add_interface failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90370", " - wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90372", " - wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90374", " - wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[]", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90375", " - wifi: mt76: fix non-AQL packet accounting for MLO stations", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90378", " - wifi: mt76: mt792x: Fix memory leak in SDIO TX path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90382", " - wifi: mt76: mt76x02: do not WARN on invalid rx descriptor length", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90383", " - misc: sgi-gru: remove interrupt-context page-table walks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90385", " - md/raid1: create serial pool adding rdev to array with", " serialize_policy=1", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90386", " - i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90387", " - swiotlb: Preserve allocation virtual address for dynamic pools", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90388", " - iommu/dma: Check atomic pool allocation result directly", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90389", " - md: scope memalloc_noio to allocation critical sections", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90390", " - md/bitmap: resume array on backlog_store() error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90391", " - lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90392", " - bpf: Fix potential UAF when reading bpf link info", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90393", " - bpf: Fix potential UAF in bpf_netns_link_update_prog", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90394", " - power: supply: sc2731_charger: cancel work on remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90395", " - power: supply: isp1704_charger: cancel work on remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90397", " - firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is", " published", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90398", " - wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90399", " - wifi: ath12k: fix stride mismatch in mac_phy_caps_parse()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90400", " - md: recheck spare changes before starting sync", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90403", " - wifi: rtlwifi: pci: fix error path in rtl_pci_probe()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90404", " - platform/chrome: cros_ec_debugfs: Unregister panic notifier", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90407", " - wifi: ath11k: fix overreads in", " ath11k_wmi_process_csa_switch_count_event()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90410", " - spi: davinci: switch to managed controller allocation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90411", " - nvme-fc: unmap cmd_iu DMA on rsp_iu mapping failure in init_request", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90413", " - IB/isert: reject login PDUs declaring more data than was received", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90414", " - IB/isert: reject PDUs declaring more data than was received", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90415", " - RDMA/cxgb4: free STAG index when TPT entry write fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90416", " - RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90418", " - nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90419", " - nilfs2: prevent out-of-bounds read in super root block parsing", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90420", " - nilfs2: fix infinite loop in nilfs_clean_segments()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89782", " - fs/ntfs3: reject restart table growth beyond U16_MAX entries", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90431", " - remoteproc: Prevent crash handling to race with rproc_del()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90433", " - spi: oc-tiny: switch to managed controller allocation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90434", " - isofs: release zisofs block pointer buffer head", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90435", " - RDMA/mlx5: Fix integer overflow of user QP buffer size", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92476", " - crypto: keembay - Initialize completion before requesting IRQ", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92477", " - scsi: ufs: debugfs: Reserve space for a string terminator", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92481", " - pinctrl: mediatek: free EINT resources on unbind", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92484", " - cxl/region: Fix use-after-free in find_pos_and_ways() error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89785", " - fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92488", " - RDMA/erdma: complete object teardown when the destroy command fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92489", " - xfrm: Fix skb double-free in xfrm_dev_direct_output()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92490", " - firmware: arm_scmi: Unrequest devices if driver registration fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89787", " - ext4: check dir entry fits before reading the hash trailer in", " ext4_search_dir()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92494", " - ext4: fix buffer_head leak in ext4_init_orphan_info", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92495", " - RDMA/bnxt_re: Clear VM_MAYWRITE on DBR/toggle page mmap", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92496", " - wifi: ath11k: Avoid buffer overread in ath11k_wmi_tlv_op_rx()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92497", " - wifi: ath12k: Avoid buffer overread in ath12k_wmi_op_rx()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92498", " - wifi: ath6kl: avoid buffer overreads in WMI event handlers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92501", " - ext4: drain in-flight DIO before buffered write fallback", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92504", " - thermal: intel: int3400: clean up ODVP on probe failures", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92506", " - firmware: arm_scmi: Fix requested device removal race", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92507", " - RDMA/core: Fix potential use after free in ib_dealloc_pd_user()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92508", " - RDMA/core: Fix potential use after free in ib_free_cq()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92509", " - RDMA/core: Fix potential use after free in counter_release()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92510", " - RDMA/core: Fix potential use after free in ib_destroy_srq_user()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92511", " - RDMA/core: Fix potential use after free in ib_destroy_cq_user()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92512", " - RDMA/core: Fix use after free in ib_query_qp()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-74334", " - RDMA/nldev: Fix locking when accessing mr->pd", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92514", " - RDMA/erdma: Fix CEQ tasklet use-after-free on removal", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92519", " - riscv, bpf: Fix memory leak in bpf_jit_free", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89786", " - ext4: fix out-of-bounds read in ext4_read_inline_dir()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92521", " - ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92522", " - ACPI: processor: validate MADT IOAPIC entry bounds", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92523", " - RDMA/nldev: validate dynamic counter attribute length", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92524", " - irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-92525", " - RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93037", " - RDMA/hfi1: Propagate sdma_txinit_ahg() errors", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93039", " - ASoC: meson: Keep link pointers valid on realloc failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93040", " - dmaengine: dw-edma: Serialize channel state checks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93041", " - dmaengine: dw-edma: Serialize abort state updates", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93042", " - dmaengine: dw-edma: Terminate all descriptors without callbacks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93046", " - software node: Fix software_node_get_reference_args() with index -1", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93048", " - mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93049", " - mtd: mtdswap: Avoid freeing registered blktrans device twice", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89777", " - vfio/pci: clear vdev->msi_perm after freeing it on init failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93050", " - ipack: ipoctal: fix UAF, null-ptr-deref, and use-after-free in cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93051", " - misc: ad525x_dpot: use driver core groups for sysfs files", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93052", " - misc: bcm-vk: Use acquire/release for msgq_inited", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93053", " - speakup: keyhelp: guard letter_offsets possible out-of-range indexing", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93054", " - uio: Fix stale info pointer in failed registration path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93055", " - UDF symlink pathComponent header OOB read", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93056", " - usb: gadget: f_uac1_legacy: remove broken string configfs attributes", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93061", " - gpu: host1x: Avoid stack over-read in debug output helpers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93062", " - wifi: iwlwifi: guard against division by zero in", " iwl_dbg_tlv_alloc_fragments", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93063", " - wifi: iwlwifi: mei: check SAP message length before reading it", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93064", " - wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93065", " - wifi: iwlwifi: fix counter type in iwl_fwrt_dump_error_logs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93067", " - drm/bridge: tc358767: clamp the reported AUX read size to the request", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93072", " - irqchip/renesas-irqc: Fix generic interrupt chip leak on remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93073", " - dax: read holder_ops once in dax_holder_notify_failure()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93083", " - firmware: arm_scmi: Unwind TX receiver mailbox setup failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93084", " - firmware: arm_scmi: Drop handle on protocol bind failures", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93085", " - firmware: arm_scmi: Reject out of range DT protocol IDs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93086", " - firmware: arm_scmi: Avoid IDR updates while cleaning channels", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93089", " - firmware: arm_scmi: Free transport channel on IDR failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93090", " - firmware: arm_scmi: Clean up channels on setup failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93092", " - firmware: arm_scmi: Unregister device notifier before IDR teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93093", " - firmware: arm_scmi: Publish channel state before callbacks", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93095", " - hfsplus: validate thread record before delete key rebuild", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90048", " - fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2024-52560", " - fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93097", " - cxl/mbox: Break poison list loop on an empty payload", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93098", " - rpmsg: glink: fix deadlock in endpoint destroy during driver detach", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93101", " - media: v4l2-async: Unregister sub-device if asc_list is empty", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89778", " - isofs: fix out-of-bounds page array access on empty zisofs block", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93102", " - RDMA/hfi1: Free RX data on late probe failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93103", " - RDMA/hfi1: Preserve unit 0 on allocation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89783", " - xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is", " full", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93107", " - RDMA/rxe: Avoid reprocessing the current packet after the QP enters the", " error state", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93108", " - RDMA/ipoib: Drain RCU callbacks during module teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93109", " - RDMA/mlx5: Drain RCU callbacks during module teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93110", " - RDMA/core: Wait for RCU callbacks before unloading ib_core", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93113", " - clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93114", " - platform/surface: acpi-notify: Check ACPI companion before use", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93115", " - platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93117", " - usb: fix UAF when probe runs concurrent to dyn ID removal", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93118", " - usb: gadget: aspeed_udc: check endpoint DMA allocation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93119", " - usb: ljca: bound bank_num in ljca_enumerate_gpio()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93120", " - usb: gadget: configfs: fix out-of-bounds read of qw_sign", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93126", " - remoteproc: qcom_q6v5_adsp: Fix reference leak for device node", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93130", " - platform/x86: dell-wmi-base: Fix resource leak on module load failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93131", " - platform/x86: dell-privacy: Fix race condition", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93136", " - bus: mhi: ep: Fix device refcount leak in the error path of MHI device", " creation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93137", " - bpf: Fix use-after-free on mm_struct in bpf_find_vma()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93138", " - bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93140", " - udf: Mark LVID buffer as uptodate before marking it dirty", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93141", " - usb: gadget: r8a66597: avoid double free of ep0_req in probe error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93142", " - thermal/drivers/rcar: Fix error checking in probe()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93145", " - clk: qcom: gdsc: tear down per-domain genpds in gdsc_unregister()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93149", " - wifi: mac80211_hwsim: avoid NULL skb in stop queue drain", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93150", " - cgroup/cpuset: Make nr_deadline_tasks an atomic_t", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93151", " - nvmet-rdma: fix response resource leak on queue teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93152", " - nvme-apple: Use acquire/release for queue enabled state", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93155", " - crypto: keembay - Fix AEAD unregister count in error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93156", " - crypto: rk3288 - fail ahash requests on HASH idle timeout", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93158", " - crypto: sa2ul - stop probe if context pool creation fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93159", " - crypto: atmel-sha204a - fix heap info leak on I2C transfer failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93160", " - crypto: atmel-ecc - reject hardware ECDH without a public key", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93161", " - crypto: qat - clear AES key schedule from stack", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93162", " - crypto: qat - cancel work on re-enable SR-IOV timeout", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93163", " - hwrng: core - fix rng list on registration error", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93165", " - platform/chrome: sensorhub: Fix memory overread in ring handler", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93167", " - csky: Fix a4/a5 restoration in syscall trace path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93170", " - dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and", " MCDMA interrupt handlers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93172", " - mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93174", " - bpf: Copy per-CPU map value padding in copy_map_value_long()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93177", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93178", " - drm/amdgpu/pm/powerplay: bounds-check voltage index in SMU7 lookup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93182", " - sched/fair: Fix overflow in update_tg_cfs_runnable()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93183", " - drm/lima: call drm_mm_init() with a valid allocation range", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93184", " - ASoC: fsl_audmix: rework runtime PM handling in probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93185", " - ASoC: rt700-sdw: always drain jack work on remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93186", " - cxl/mbox: Clamp mailbox output allocation to the payload size", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93188", " - HID: roccat: bound device-supplied profile index", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93189", " - HID: core: quiesce input in hid_hw_stop() to prevent use-after-free", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93190", " - platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93191", " - smack: fix incorrect task context in smack_msg_queue_msgrcv", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93192", " - drm/v3d: Clear queue->active_job when v3d_fence_create() fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89947", " - clk: meson: align gxbb_32k_clk_sel number of parents with actual count", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-80671", " - perf sched: Fix register_pid() overflow, strcpy, and BUG_ON", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93203", " - batman-adv: bla: avoid CRC corruption due to parallel claim add", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-93204", " - batman-adv: dat: atomically update mac addresses", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-23137", " - of: unittest: Fix memory leak in unittest_data_add()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89970", " - nvmet-auth: Synchronize timeout work during SQ teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-64210", " - net/mlx5e: xsk: Fix unlocked writing to ICOSQ", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89794", " - ksmbd: zero pipe read compound padding", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90015", " - xhci: fix lost bounce buffers on TDs spanning several ring segments", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-80878", " - afs: Fix leak of ungot volume", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89800", " - drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89801", " - drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89802", " - drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89803", " - drm/nouveau: unsubscribe the channel-kill event before the fence context", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89816", " - drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89817", " - drm/gud: NUL-terminate TV mode names read from the device", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89818", " - drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89819", " - drm/amd/display: validate plane degamma LUT size for private color prop", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89821", " - drm/amd/display: avoid divide-by-zero in __is_lut_linear()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89822", " - drm/i915: Guard against NULL driver_data in i915_pci_probe()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89823", " - drm: fix race between partial drm_dev_register() failure and ioctl", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89824", " - drm/panel-edp: fix i2c adapter leak on probe failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89830", " - f2fs: fix valid block count leak on data block allocation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89834", " - f2fs: fix to migrate all curseg types during free_segment_range", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89835", " - f2fs: avoid NULL checkpoint thread access in sysfs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89839", " - f2fs: use the mount idmap for the owner check in f2fs_xattr_advise_set()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89842", " - scsi: qla2xxx: Skip NVMe LS reject IOCB when FW not started", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89843", " - scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89844", " - scsi: qla2xxx: Hold vport_slock for host map update in report ID", " acquisition", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89845", " - scsi: qla2xxx: Avoid req_q_map double-read in qla2x00_error_entry()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89846", " - scsi: qla2xxx: Bound rsp_info_len to avoid OOB sense-data read", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89847", " - scsi: qla2xxx: Avoid double completion in async IOCB timeout", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89848", " - scsi: qla2xxx: Quiesce response IRQ before freeing request queue", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89849", " - scsi: qla2xxx: Reject non-SCSI SRB on status IOCB fast path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89850", " - scsi: qla2xxx: Don't query firmware state while chip is down", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89851", " - scsi: qla2xxx: Fix FCE trace enable parsing in debugfs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89852", " - scsi: qla2xxx: Zero mailbox struct in qla2x00_get_firmware_state()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89853", " - scsi: qla2xxx: Fix FCE trace use-after-free during firmware dump", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89854", " - scsi: qla2xxx: Fix cs84xx use-after-free on host teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89855", " - scsi: qla2xxx: Serialize flash version read in reset handler", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89856", " - scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89857", " - scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89858", " - scsi: qla2xxx: Bound image count in qla2x00_update_fru_versions()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89860", " - scsi: qla2xxx: Initialize NVMe abort_work once at submission", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89861", " - scsi: qla2xxx: Hold vport reference in qla24xx_report_id_acquisition()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89863", " - scsi: qla2xxx: edif: Fix NULL pointer deref in RX SA delete check", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89864", " - scsi: qla2xxx: Bound i2c->length in I2C bsg handlers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89865", " - scsi: qla2xxx: Zero SFP DMA buffer in FRU/I2C bsg handlers", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89870", " - media: zoran: Avoid freeing a registered video_device twice", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89871", " - media: video-i2c: fix kthread error pointer left in kthread_vid_cap on", " failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89872", " - media: v4l2-fwnode: Fix fwnode leak in v4l2_fwnode_parse_link", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89874", " - media: v4l2-async: avoid deleting unlinked ASC entry on link error", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89876", " - media: tda18250: fix possible integer overflow", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89877", " - media: saa7164: fix cleanup on resource allocation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89878", " - media: s2255: check firmware size before reading trailing marker", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89879", " - media: s2255: bound JPEG frame size before copying into the buffer", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89880", " - media: rtl2832_sdr: release URBs and stream buffers on start_streaming()", " failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89881", " - media: rtl2832_sdr: use vb2_video_unregister_device() on remove to fix", " DMA leak", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89883", " - media: rc: sunxi-cir: Unregister rc device on probe failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89884", " - media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89887", " - media: i2c: ov7740: fix use-after-destroy in remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89888", " - media: i2c: ov02a10: fix endpoint parsing use-after-free", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89890", " - media: go7007: defer the ALSA v4l2 put until card release", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89891", " - media: em28xx: fix use-after-free of dev_next->devlist on disconnect", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89892", " - media: em28xx: defer audio-only extension registration", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89893", " - media: cx23885: cancel NetUP CI work before teardown", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89894", " - media: cx231xx: reject geometry changes while the VBI queue is busy", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89895", " - media: cobalt: Avoid freeing ALSA private data twice", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89896", " - media: cedrus: fix memory leak in cedrus_init_ctrls()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89897", " - media: cec: Serialize exclusive follower delivery", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89899", " - media: cec: disable delayed work before freeing an interrupted transmit", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89900", " - media: cec: core: Fix kmemleak due to missed rc_free_device() call", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89901", " - media: airspy: use vb2_video_unregister_device() on disconnect to fix", " NULL deref", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89902", " - LoongArch: Avoid preempt count underflow without probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89903", " - LoongArch: Do not save/restore percpu base register in rethook", " trampoline", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89908", " - LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89909", " - LoongArch: KVM: Free init resources if kvm_init() fails", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89922", " - KVM: s390: Take srcu when importing watchpoint data", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89923", " - KVM: s390: Free guest debug data on vcpu destroy", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89924", " - KVM: s390: Fix old_data leak in guest debug error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89925", " - KVM: s390: Fix memory leak in guest debug handling", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89926", " - KVM: s390: Fix length check __import_wp_info()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89927", " - KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89929", " - KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89930", " - KVM: nVMX: Service local TLB flushes on failed nested VM-Enter", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89931", " - KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89932", " - KVM: nVMX: Always flush vpid02 on first use", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89933", " - iio: pressure: dps310: fix NULL pointer dereference on ACPI probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89934", " - iio: light: ltrf216a: fix runtime PM reference leak in error path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89936", " - iio: dac: m62332: Fix regulator reference count imbalance", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89937", " - iio: chemical: sgp30: Handle IAQ thread creation failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89938", " - iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove", " UAF", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89939", " - iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89944", " - ASoC: hdac_hda: Fix hlink refcount leak on component registration", " failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89945", " - ASoC: cs35l34: drain threaded IRQ before runtime suspend", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89946", " - ASoC: cs35l33: drain threaded IRQ before runtime suspend", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89948", " - batman-adv: bla: fix freeing of claims on meshif deletion", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89949", " - batman-adv: dat: avoid unaligned fault in IP extraction", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89950", " - batman-adv: mcast: linearize skbuff for packet generation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89951", " - batman-adv: fix stale receive device on merged fragments", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89952", " - mtd: rawnand: validate ONFI extended parameter page sections", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89953", " - mtd: mtdoops: free page bitmap when the backing MTD is removed", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89954", " - mtd: afs: validate v2 image info bounds", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89955", " - s390/vfio-ap: Fix NULL deref in status_show() during queue probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89957", " - s390/vfio-ap: Fix hot-unplug skipped when last AP adapter or domain", " removed", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89958", " - s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89959", " - s390/vfio-ap: Fix control domain removal in vfio_ap_mdev_cfg_remove", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89960", " - s390/vfio-ap: fix stale pqap_hook pointer on error in", " vfio_ap_mdev_set_kvm()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89961", " - powerpc/mm: fix wrong addr_pfn tracking in compound vmemmap population", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89962", " - powerpc/kexec_file: Prevent kexec range truncation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89964", " - parisc: eisa: Fix infinite loop when parsing invalid IRQ value", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89965", " - nvdimm/btt: reject an arena whose nfree is below the lane count", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89968", " - nvmet-tcp: reject unsolicited H2CData PDUs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89969", " - nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89973", " - nvme-tcp: check the data direction of a C2HData PDU", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89975", " - nvme-fabrics: fix DHCHAP secret leak on parse failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89979", " - ALSA: pcm: Fix race between non-atomic ops and trigger-start", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89980", " - ALSA: harmony: initialize locks before requesting IRQ", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89982", " - i2c: mux: Fix channel node leak on adapter add failure", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89983", " - i2c: core: fix debugfs UAF on adapter removal", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89984", " - perf/x86/intel: Fix kernel address leakages in LBR stack", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-74268", " - tcp: clear sock_ops cb flags before force-closing a child socket", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89988", " - kprobes: Protect kprobe_blacklist with RCU", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89989", " - ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89992", " - cpuidle: dt_idle_genpd: kfree() the original name allocation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89993", " - dmaengine: dw-edma: Initialize IRQ data before requesting IRQs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89995", " - dma-direct: return struct page from dma_direct_alloc_from_pool()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89997", " - dm: fix resume-vs-remove race", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89998", " - dm: fix race when loading and unloading a table", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89999", " - HID: wacom: validate report length in wacom_intuos_pro2_bt_irq", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90000", " - HID: rmi: fix OOB access with undersized RMI reports", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90003", " - futex: Prevent rcuwait use-after-free during requeue PI", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90007", " - scsi: pm8001: Use rollback index when freeing MSI-X vectors", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90011", " - scsi: target: iscsi: Reserve a terminator byte for the login payload", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89793", " - ublk: clear VM_MAYWRITE on read-only ublk char device mmap", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90017", " - staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90018", " - staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90019", " - usb: gadget: fix null pointer dereference in usb_put_function_instance()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90020", " - USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90021", " - usb: gadget: f_midi: initialize work in f_midi_alloc()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90022", " - usb: gadget: f_midi2: fix use-after-free in string attribute show path", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90024", " - usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90025", " - usb: typec: ucsi: displayport: Fix OOB altmode array index", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90026", " - usb: typec: qcom-pmic: cancel reset_work on stop", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90031", " - usb-storage: ene_ub6250: fix race between scan work and probe", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90032", " - media: usbtv: keep device alive while ALSA card exists", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90033", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90034", " - usb: image: mdc800: change kmalloc() to kzalloc()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90035", " - drm/amd/display: fix division by zero in get_estimated_bw()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89603", " - entry: Fix seccomp bypass after ptrace with TSYNC", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89595", " - fsnotify: Fix stale object mask after concurrent mark updates", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-80933", " - wifi: mt76: mt7996: validate default EEPROM firmware size", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-53250", " - xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89560", " - landlock: Require LANDLOCK_ACCESS_FS_MAKE_REG for whiteout creation", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-89488", " - openvswitch: Fix CT limit teardown use-after-free", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-90049", " - net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2024-56639", " - net: hsr: must allocate more bytes for RedBox support", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2026-23201", " - ceph: fix oops due to invalid pointer for kfree() in parse_longname()", "", " * Noble update: upstream stable patchset 2026-10-06 (LP: #2169822) //", " CVE-2025-37833", " - net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770)", " - netfilter: nf_conntrack_expect: restore helper propagation via", " expectation", " - netfilter: br_netfilter: Reallocate headroom if necessary in", " neigh_hh_bridge()", " - 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", " - pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151", " - ata: sata_mv: accept 1 or 2 resources in platform probe", " - ata: libahci_platform: support non-consecutive port numbers", " - ahci: Introduce ahci_ignore_port() helper", " - ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources()", " - 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: 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", " - ipvs: fix places with wrong packet offsets", " - ipvs: do not mangle ICMP replies for non-first fragments", " - pinctrl-amd: Don't clear S4 wake bits at probe", " - smb: client: fix buffer leaks in SMB1 read and write", " - spi: spi-cadence: supports transmission with bits_per_word of 16 and 32", " - spi: spi-cadence: Move TX FIFO full busy-wait into FIFO", " - 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", " - hwmon: (pmbus) Fix return value from pmbus_update_byte_data()", " - Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos", " - Bluetooth: hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists", " - Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync", " - net: phylink: put link_gpio if phylink_create fails", " - scsi: ufs: core: Cancel RTC work in active-active suspend", " - scsi: zfcp: Fix memory leak during adapter release by destroying", " gid_pn_req", " - scsi: target: Clear cmd_cnt when initial counter enrollment fails", " - 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()", " - accel/qaic: use sizeof(*trans_hdr) for transaction length check", " - net: dsa: mt7530: error out on failed reads in MT7531 PHY polling", " - octeontx2-pf: Set correct sequence for carrier off and tx queue stop", " - ksmbd: return success for deferred final close", " - pinctrl: microchip-sgpio: add missing select REGMAP_MMIO", " - pinctrl: bm1880: add missing select GENERIC_PINCONF", " - mm/vmstat: fold stranded per-cpu node stats when a node comes online", " - tracing/probes: Reject $arg0 in meta argument expansion", " - audit: fix potential integer overflow in audit_log_n_string()", " - Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()", " - Bluetooth: mgmt: fix pending command UAF in EIR updates", " - bpf: lwt: Fix dst reference leak on reroute failure", " - ALSA: lx6464es: fix period byte count for 16-bit streams", " - ASoC: tas2562: fix DVC coefficient write order", " - ASoC: tas2562: fix broken entries in the volume lookup table", " - ata: libata-eh: Increase STANDBY IMMEDIATE timeout", " - dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+", " - e1000: fix memory leak in e1000_probe()", " - powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()", " - vxlan: unclone skb head before modifying eth header in", " route_shortcircuit()", " - tracing/filters: Fix false positive match in regex_match_full()", " - spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure", " - selftests/mm: fix potential wild pointer access of getline due to", " missing init", " - selftests/clone3: fix wild pointer access of getline due to missing init", " - hwmon: (npcm750-pwm-fan): stop fan timer on device detach", " - hwmon: (pmbus/core) notify on the hwmon device, not the i2c client", " - gpio: pca953x: fix cache_only and IRQ state on restore_context() failure", " - cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()", " - power: supply: bq25890: fix the -10 C NTC lookup entry", " - 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", " - net: openvswitch: fix skb leak on flow key update failure during", " recirculation", " - ice: wait for reset completion in ice_resume()", " - ice: fix memory leak in ice_lbtest_prepare_rings()", " - can: c_can: c_can_chip_config(): keep controller in init mode until", " bittiming is configured", " - can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb", " allocation failure", " - can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking", " - can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in", " kvaser_usb_hydra_get_busparams()", " - can: ctucanfd: add missing MODULE_DEVICE_TABLE()", " - can: ctucanfd: use self-test mode for PRESUME_ACK", " - can: ctucanfd: unmap BAR0 using base address", " - can: ctucanfd: handle bus error interrupts", " - can: ctucanfd: mark error-active controller status valid", " - drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs", " - drm/mediatek: ovl_adaptor: balance component registrations", " - drm/amdgpu: restore UMD profile pstate after runtime resume", " - drm/amdgpu: cap GTT size to physical RAM on APUs", " - drm/amdkfd: Handle invalid event type in CRIU event restore", " - spi: spi-cadence: enable SPI_CONTROLLER_MUST_TX", " - HID: logitech-dj: Fix maxfield check in DJ short report validation", " - ata: libahci_platform: Do not set mask_port_map when not needed", " - ata: ahci: Make ahci_ignore_port() handle empty mask_port_map", " - usb: typec: ucsi: Only enable supported notifications", " - usb: typec: ucsi: split connector lock classes", " - SAUCE: Revert \"UBUNTU: SAUCE: usb: typec: ucsi: Fix workqueue", " destruction race during connector cleanup\"", " - drm/fb-helper: Allocate and release fb_info in single place", " - drm/tegra: fbdev: Remove offset into framebuffer memory", " - drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions", " - drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable()", " - media: i2c: imx219: Rename VTS to FRM_LENGTH", " - media: imx219: Fix maximum frame length in lines", " - rxrpc: Fix irq-disabled in local_bh_enable()", " - netfilter: nf_tables: clone set on flush only", " - wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress", " (CYW)", " - wifi: brcmfmac: set F2 blocksize to 256 for BCM43752", " - can: use skb hash instead of private variable in headroom", " - can: isotp: fix timer drain order, wakeup handling and tx_gen ordering", " - mptcp: pm: avoid code duplication to lookup endp", " - mptcp: add mptcp_userspace_pm_lookup_addr helper", " - mptcp: pm: use addr entry for get_local_id", " - drm/i915/fbc: Extract intel_fbc_has_fences()", " - drm/i915/hdcp: migrate away from kdev_to_i915() in bind/unbind", " - drm/i915/hdcp: Move to using intel_display in intel_hdcp", " - drm/i915/hdcp: require monotonically increasing seq_num_v", " - ALSA: hda: codecs: hdmi: disable keep-alive before audio format change", " - drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info", " - usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path", " - mount: honour SB_NOUSER in the new mount API", " - selftests/bpf: Fail unbound UDP on sockmap update", " - ARM: npcm: Fix OF node refcount leaks in SMP setup", " - ARM: dts: BCM5301X: fix PCIe controller 2 second interrupt", " - drm/bridge: ps8640: propagate AUX transfer register errors", " - Revert \"net: thunderbolt: Enable end-to-end flow control also in", " transmit\"", " - netfilter: ipset: switch ext_size to atomic64_t", " - ipvs: return the csum validation for forward hook", " - net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete", " - counter: microchip-tcb-capture: Fix DT channel validation", " - bpf: tcp: Make mem flags configurable through bpf_iter_tcp_realloc_batch", " - bpf: tcp: Make sure iter->batch always contains a full bucket snapshot", " - bpf: tcp: Get rid of st_bucket_done", " - bpf: tcp: Use bpf_tcp_iter_batch_item for bpf_tcp_iter_state batch items", " - bpf: tcp: Avoid socket skips and repeats during iteration", " - vhost/vdpa: reject overflowing PA map page counts on 32-bit", " - tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss()", " - net: sched: cls_api: add skip_sw counter", " - net: sched: cls_api: add filter counter", " - net: sched: make skip_sw actually skip software", " - net: sched: cls_api: fix slab-use-after-free in fl_dump_key", " - net: sched: refine software bypass handling in tc_run", " - hwmon: (nzxt-smart2) Check return value of init_device() in probe", " - hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations", " - selftests/ftrace: refactor eprobes test to fix argument checks", " - bnxt_en: Do not set EOP on RX AGG BDs on 5760X chips", " - bnxt_en: Fix PTP PPS setting bug", " - sctp: fix addip_serial increment on ASCONF_ACK allocation failure", " - tls: don't abort the connection on signal-interrupted sends", " - hwmon: (corsair-psu) fix possible out-of-bounds access on missing string", " termination", " - regulator: devres: add API for reference voltage supplies", " - hwmon: (ads7828) Fix external VREF regulator handling", " - net: fec: do not release NULL pages when RX buffer allocation fails", " - spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers", " - thunderbolt: icm: Preserve USB4 proxy data-valid bit", " - usb: cdnsp: fix incorrect endian conversions for APB timeout register", " - ipvs: add totalconns for dest", " - ipvs: properly update the overload flag on dest edit", " - net: octeontx2-pf: Fix UB in shift operation", " - KVM: s390: pci: Fix missing error codes and memory unaccounting", " - KVM: s390: pci: Fix resource leak on IRQ registration failure", " - KVM: s390: pci: Fix aisb calculation", " - dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk", " - fortify: refactor test_fortify Makefile to fix some build problems", " - fortify: Disable -Wstringop-overread in tests", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - selftests/bpf: Adapt sockmap update error handling", " - mei: pull kvfree out of spinlock", " - misc: fastrpc: fix channel ctx ref leak when session alloc fails", " - misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free", " - ALSA: usb: Fix UAF at delayed release of MIDI2 EPs", " - scsi: scsi_debug: Negate wrapped memcmp() result", " - bpf: tcp: fix double sock release on batch realloc", " - regulator: devres: fix devm_regulator_get_enable_read_voltage() return", " - ipvs: separate destination availability state", " - net: mana: Fix EQ leak in mana_remove on NULL port", " - selftests: mptcp: join: mark tests with data corruption as failed", " - ASoC: cs4265: sort the register default table", " - ASoC: cs35l45: sort the register default table", " - ASoC: cs35l41: sort the register default table", " - drm/amdgpu: fix aperture iounmap skipped on device removal", " - Input: xpad - add support for ZENAIM LEVERLESS", " - powerpc/pseries: pci - logic bug", " - Input: atkbd - skip deactivate for Xiaomi Book Pro 14's internal", " keyboard", " - powerpc/pseries: lparcfg - fix kbuf[] underflow", " - ftrace: Protect direct_functions in ftrace_find_rec_direct", " - ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()", " - Input: sur40 - fix V4L error path cleanup", " - ceph: fix MDS random selection readiness predicate", " - libceph: tolerate addrvecs with multiple entries of the same type", " - mmc: omap_hsmmc: fix busy_timeout overflow in ns conversion on 32-bit", " - mmc: sdhci: unmap the bounce buffer before device release", " - mmc: sdhci: make tuning_err a signed int", " - drm/radeon: fix autosuspend cleanup during teardown", " - drm/amdgpu: Implement insert_end for VCE 3", " - drm/amdgpu: Fix UVD min buffer sizes", " - xfs: only check mergeability of bnobt records", " - xfs: check v5 superblock features early", " - ceph: Remove ceph_writepage()", " - ceph: Use a folio in ceph_page_mkwrite()", " - libceph: Amend checking to fix `make W=1` build breakage", " - mm: userfaultfd: add pgtable_supports_uffd_wp()", " - userfaultfd: move vma_can_userfault out of line", " - smb: move smb_version_values to common/smbglob.h", " - smb: move get_rfc1002_len() to common/smbglob.h", " - smb/server: rename include guard in smb_common.h", " - ksmbd: rename smb2_get_msg to smb_get_msg", " - smb/server: fix minimum SMB2 PDU size", " - tcp: Pass flags to __tcp_send_ack", " - tcp: fast path functions later", " - btrfs: add debug build only WARN", " - btrfs: add space_info argument to btrfs_chunk_alloc()", " - btrfs: remove fs_info argument from btrfs_zoned_activate_one_bg()", " - btrfs: zoned: fix missing chunk metadata reservation", " - ksmbd: conn lock to serialize smb2 negotiate", " - net: pktgen: fix code style (WARNING: Block comments)", " - fs: don't block write during exec on pre-content watched files", " - ice: fix VF interrupts cleanup", " - vxlan: Do not alloc tstats manually", " - net: core,vrf: Change pcpu_dstat fields to u64_stats_t", " - vrf: Make pcpu_dstats update functions available to other modules.", " - vxlan: Handle stats using NETDEV_PCPU_STAT_DSTATS.", " - i2c: bcm-iproc: remove printout on handled timeouts", " - i2c: iproc: reset bus after timeout if START_BUSY is stuck", " - can: rcar_canfd: change the initializing flow for clocks and resets", " - drm/amd/pm: fix torn gpu metrics reads", " - drm/amdgpu: move debug_vm handling to amdgpu_cs_parser_fini", " - mm/pagewalk: split walk_page_range_novma() into kernel/user parts", " - arm64: tegra: Add EL2 virtual timer interrupt for Tegra194", " - crypto: ccm - Set rfc4309 maxauthsize from child", " - netfilter: ipset: fix list type element drift bug", " - netfilter: ipset: let destroy callbacks adjust ext mem size", " - m68k: Define NR_CPUS to 1", " - erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms", " - binfmt_misc: use exe_file_deny_write_access() for the interpreter clone", " - ring-buffer: Remove jump to out label in ring_buffer_swap_cpu()", " - perf: Unify perf_event_free_task() / perf_event_exit_task_context()", " - serial: sc16is7xx: fix copy-paste errors in EFR_SWFLOWx_BIT constants", " - serial: sc16is7xx: convert bitmask definitions to use BIT() macro", " - serial: sc16is7xx: rename EFR mutex with generic name", " - serial: sc16is7xx: use guards for simple mutex locks", " - serial: sc16is7xx: enable THRI before filling TX FIFO", " - inet: frags: add inet_frag_putn() helper", " - ipv4: frags: remove ipq_put()", " - inet: frags: change inet_frag_kill() to defer refcount updates", " - inet: frags: save a pair of atomic operations in reassembly", " - xfs: don't use a xfs_log_iovec for ri_buf in log recovery", " - null_blk: fix UBSAN shift-out-of-bounds when zone_size is 0 or overflows", " - ext4: clear error before retrying inode xattr space fallback", " - s390/vfio_ccw: Calculate idal length based on idaw type", " - drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix", " - drm/amdgpu: check ASPM on the dGPU host link", " - nfc: nci: free destination parameters when closing a connection", " - ndisc: ndisc_send_redirect() cleanup", " - ASoC: sof: pcm: use snd_pcm_direction_name()", " - ASoC: SOF: Relocate and rework functionality for PCM stream freeing", " - ASoC: SOF: pcm: Move period/buffer configuration print after platform", " open", " - ASoC: SOF: pcm: Add snd_sof_pcm specific wrappers for dev_dbg() and", " dev_err()", " - mptcp: pm: fix data race in add_addr timer callback", " - HID: magicmouse: fix battery reporting for Bluetooth Magic Trackpad", " USB-C", " - HID: magicmouse: Prevent out-of-bounds (OOB) read during", " DOUBLE_REPORT_ID", " - Input: atkbd - skip deactivate for HONOR FMB-P's internal keyboard", " - Input: atkbd - skip deactivate for HONOR ZQC-P", " - net: gro: properly validate BIG TCP aggregation criteria", " - KVM: x86/mmu: Check write tracking in all address spaces", " - io_uring/io-wq: fix worker accounting when canceling creation callbacks", " - can: j1939: add missing calls in NETDEV_UNREGISTER notification handler", " - can: j1939: make j1939_sk_bind() fail if device is no longer registered", " - ASoC: nau8821: Cancel pending work before suspend", " - smc: Use __sk_dst_get() and dst_dev_rcu() in smc_vlan_by_tcpsk().", " - selinux: switch two allocations to use kzalloc_objs()", " - ksmbd: harden file lifetime during session teardown", " - ext4: make some fast commit functions reuse extents path", " - ext4: propagate errors from fast commit range replay", " - nilfs2: correct return value kernel-doc descriptions for ioctl functions", " - HID: magicmouse: re-enable multitouch after reset-resume", " - HID: ft260: validate i2c input report length", " - HID: pidff: clang-format pass", " - Bluetooth: hci_sync: Use bt_dev_err() to log error message in", " hci_update_event_filter_sync()", " - xfs: remove file_path tracepoint data", " - fpga: dfl: fme: add error handling", " - accessibility: speakup: unregister tty ldisc on later init failures", " - usb: xhci: Handle USB3 port events when there is one roothub", " - xhci: dbgtty: Fix unregister on tty_alloc_driver() failure", " - usb: usbtest: disable dynamic ID support", " - x86/CPU/AMD: Carve out a Zen5 models range", " - mm/swap: reject swapon() on filesystem-level encrypted files", " - crypto: atmel-tdes - use scatterlist length before DMA mapping", " - crypto: qce - Remove unsafe/deprecated algorithms", " - usb: core: Strengthen error handling in hub_hub_status()", " - USB: serial: spcp8x5: drop broken carrier detect support", " - um: Add os_set_pdeathsig helper function", " - um: Set parent death signal for winch thread/process", " - um: Use os_set_pdeathsig helper in winch thread/process", " - um: Set parent-death signal for ubd io thread/process", " - um: Set parent-death signal for write_sigio thread/process", " - um: Set parent death signal for userspace process", " - kunit: tool: Terminate kernel under test on SIGINT", " - kunit: tool: skip stty when stdin is not a tty", " - um: Preserve errno within signal handler", " - pinctrl: qcom: Unconditionally mark gpio as wakeup enable", " - btrfs: fix leaking BTRFS_FS_STATE_REMOUNTING flag", " - Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep", " annotation", " - hwmon: (ina2xx) Add support for has_alerts configuration flag", " - hwmon: (ina2xx) Add support for INA260", " - hwmon: (ina226) Add support for SY24655", " - hwmon: (ina2xx) Make it easier to add more devices", " - hwmon: (ina2xx) Add support for INA234", " - hwmon: (ina2xx) Shift INA234 shunt and current registers", " - hwmon: (ina2xx) Fix various overflow issues", " - net: ethernet: mtk_eth_soc: support named IRQs", " - net: ethernet: mtk_eth_soc: add consts for irq index", " - idpf: Fix mailbox IRQ name leak on request failure", " - Bluetooth: ISO: validate sockaddr_iso first in iso_sock_rebind_bis()", " - tracing: Remove TRACE_EVENT_FL_FILTERED logic", " - tracing/mmiotrace: Remove reference to unused per CPU data pointer", " - net: dsa: mt7530: check bus->read() errors in the MDIO regmap backend", " - fs/proc/task_mmu: fix PAGEMAP_SCAN written state for PMD holes", " - Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req()", " - ALSA: seq: Fix division by zero in initialize_timer()", " - ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes", " - ata: libata-sata: fix ata_scsi_lpm_supported() iteration", " - cpufreq: schedutil: Publish util hooks only after all sg_cpu are", " initialized", " - s390/pci: Fix s390_pci_mmio_write syscall error return without MIO", " - drm/amd/display: Increase HDMI AV mute wait from 2 to 3 frames", " - Bluetooth: ISO: fix CONNECTED -> CLOSED transition on shutdown/release", " - fs/proc/task_mmu: fix PAGEMAP_SCAN written state for unpopulated ptes", " - media: chips-media: wave5: Support CBP profile", " - drm/exec: Remove the index parameter from", " drm_exec_for_each_locked_obj[_reverse]", " - drm/xe/sched_job: Promote xe_sched_job_add_deps()", " - drm/xe: Normalize bo flags macros", " - drm/xe: Rename ___xe_bo_create_locked()", " - rxrpc: Generate rtt_min", " - rxrpc: Adjust the rxrpc_rtt_rx tracepoint", " - rxrpc: Fix the calculation and use of RTO", " - rxrpc: Manage RTT per-call rather than per-peer", " - drm/amd/display: Add AV mute wait frames to dce110_set_avmute", " - drm/amd/display: Check for tg ops in dce110_set_avmute", " - net: hns3: fix speed configuration residue after driver reload", " - pds_core: keep the health thread stopped during reset", " - blk-mq: reinsert cached request to the list", " - crypto: ccp - Add new SEV/SNP platform shutdown API", " - KVM: SVM: Add support to initialize SEV/SNP functionality in KVM", " - selftests/bpf: Ensure UDP sockets are bound", " - nvmem: layouts: Add fixed-layout driver", " - fsverity: Fix silent truncation in bpf_get_fsverity_digest()", " - mtd: ubi: skip programming unused bits in ubi headers", " - ubi: fastmap: fix ubi->fm memory leak", " - crypto: ccp: Add external API interface for PSP module initialization", " - KVM: SVM: Ensure PSP module is initialized if KVM module is built-in", " - pmdomain: arm: Fix -EINVAL from scmi_pd_set_perf_state() on state 0", " - drm/xe: Order ring writes before ring tail updates", " - drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE", " - xfs: clear zapped attr fork state when bmap repair finds no attr fork", " - ceph: Convert ceph_find_incompatible() to take a folio", " - ceph: Convert writepage_nounlock() to write_folio_nounlock()", " - ceph: fix writeback_count leak in write_folio_nounlock()", " - mm/khugepaged: guard is_zero_pfn() calls with pte_present()", " - super: remove pointless s_root checks", " - super: skip dying superblocks early", " - eventpoll: pin files while checking reverse paths", " - KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs", " - drm/vmwgfx: take fman->lock around fence list mutation in fifo_down", " - super: use a common iterator (Part 1)", " - ata: libata-scsi: terminate deferred commands on time out", " - super: use common iterator (Part 2)", " - drm/amd/pm: Use same metric table for APU", " - drm/amd/pm: Use macro to initialize metrics table", " - drm/amdgpu: remove unused function parameter", " - drm/amd/pm: adjust the visibility of pp_table sysfs node", " - ring-buffer: Simplify functions with __free(kfree) to free allocations", " - x86/mce: Remove __mcheck_cpu_init_early()", " - x86/mce: Set CR4.MCE last during init", " - tcp: fix icsk_ack.ato bitfield overflow", " - fs: unlock the superblock during iterate_supers_type", " - ALSA: hda/realtek: Enable headset mic on F+ FLAPTOP r", " - net: ethernet: mtk_eth_soc: only use legacy mode on missing IRQ name", " - net: ethernet: mtk_eth_soc: improve support for named interrupts", " - hwmon: (ltc4286) Fix symbol namespace of MODULE_IMPORT_NS()", " - xfs: namespace the maximum length/refcount symbols", " - xfs: check AGI unlinked inode buckets", " - xfs: hoist per-bucket unlinked list check to helper", " - net: dst: add four helpers to annotate data-races around dst->dev", " - ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu]", " - Bluetooth: ISO: do not force BT_LISTEN after a failed BIG sync", " - selinux: fix style issues in security/selinux/ss/avtab.h", " - selinux: fix style issues in security/selinux/ss/policydb.c", " - selinux: use known type instead of void pointer", " - selinux: avoid unnecessary indirection in struct level_datum", " - selinux: make more use of str_read() when loading the policy", " - selinux: fix style issues in security/selinux/ss/policydb.h", " - selinux: use u16 for security classes", " - selinux: fix style issues in security/selinux/ss/constraint.h", " - selinux: more strict policy parsing", " - selinux: require a class's permission values to cover its permission", " count", " - HID: pidff: Rework pidff_set_time() to fix warnings", " - HID: pidff: Use ARRAY_SIZE macro instead of sizeof", " - HID: asus: simplify RGB init sequence", " - net/tcp: fix TCP-AO key deletion in VRFs", " - crypto: qcom-rng - rename *_of_data to *_match_data", " - crypto: qcom-rng - Enable clock in hwrng case", " - f2fs: convert f2fs_compress_ctx_add_page() to use folio", " - f2fs: convert f2fs_handle_page_eio() to use folio", " - alpha: fix ieee_swcr_to_fpcr setting FPCR_DNOD unconditionally", " - alpha: don't leak hardware-fabricated FP exception bits to user space", " - clocksource/drivers/timer-sun4i: Advertise a real minimum delta", " - powerpc/pseries/iommu: switch to Default DMA window during kdump", " - include/linux/list.h: mark list_add and __list_add as __always_inline", " - mm/zswap: fix global shrinker when memory cgroup is disabled", " - mm: mempolicy: fix automatic numa balancing for shmem", " - tools/compiler: match glibc 2.42 definition of __attribute_const__", " - x86/insn-eval: Move assign_register() out of KVM as insn_assign_reg()", " - x86/tdx: Fix zero-extension for 32-bit port I/O", " - hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start()", " - tracing: Fix logged instance name on creation failure", " - cdx: Fix double free when sysfs file creation fails", " - powerpc/powermac: fix OF node refcount", " - staging: greybus: hid: fix SET_REPORT return value", " - usb: dwc2: gadget: Exit partial power down state when changing USB pull-", " up", " - USB: phy: fsl-usb: fix missing static keywords", " - usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion", " - usb: gadget: snps_udc_plat: clean up PHY on probe deferral", " - usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()", " - of: fix out-of-bounds read in of_alias_scan() stem parser", " - zsmalloc: rename class stat mutators", " - zsmalloc: account for handle size in class lookup", " - NFSD: Encode only the status in NFS-ACL v2 GETACL error replies", " - NFSD: Fix off-by-one in DRC bucket pruning limit", " - nfsd: return NFS4ERR_NOTSUPP for unsupported netloc4 types", " - nfsd: add filehandle match check to nfsd4_delegreturn()", " - nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry", " - nfsd: fix version mismatch loops in nfsd_acl_init_request()", " - nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo", " - nfsd: initialize DRC hash table before registering shrinker", " - nfsd: reject reclaim LOCK after RECLAIM_COMPLETE", " - btrfs: rename err to ret in btrfs_recover_relocation()", " - smb: client: harden DFS cache against invalid target hints", " - HID: mcp2221: stop device IO before hid_hw_stop", " - eCryptfs: bound the packet-length peek to the user buffer", " - ecryptfs: fix tag 11 packet exact-fit size check", " - ecryptfs: show filename encryption options", " - fat: restore original value when fat_ent_write failed", " - fbdev: pvr2fb: correct user pointer annotation and sentinel initializer", " - fpga: stratix10-soc: Fix SVC mailbox handling during reconfiguration", " - ACPI: APEI: Fix ERST timeout unit conversion", " - alpha/PCI: Fix I/O port accessor argument order in pci_legacy_write()", " - alpha: marvel: Fix irq_set_status_flags to use correct IRQ number", " - alpha: marvel: Fix lock ordering in init_io7_irqs()", " - ARM: 9477/1: Disable broken eBPF JIT on the Risc PC", " - block: set QUEUE_FLAG_DYING unconditionally in blk_mark_disk_dead()", " - Bluetooth: btusb: Add ASUS USB-BT540 for Realtek 8761CU", " - Bluetooth: btusb: Add ASUS USB-BT600 for Realtek 8761CU", " - dm: Constify struct dm_block_validator", " - coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior", " - cpufreq: schedutil: Fix rate limit overflow", " - cxl/pmem: Format the nvdimm serial number as unsigned decimal", " - Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on", " BCM4378", " - Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_uart: Fix false success return in hci_uart_setup()", " - Bluetooth: hci_conn: re-enable advertising only for peripheral role", " - Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb", " - Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection", " - Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is", " negative", " - Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last", " request", " - kasan: fix cache shrink race with CPU hotplug", " - ipv6: use RCU iterator to dump route exceptions", " - mailbox: qcom-ipcc: fix duplicate channel allocation across holes", " - SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry", " - SUNRPC: Guard svcauth_gss_release() dispatch on rq_auth_stat", " - jbd2: add prefix 'jbd2' for 'shrink_type'", " - jbd2: check need_resched() when skipping busy checkpoint buffers", " - ipip: fix skb leak in collect_md mode when metadata_dst allocation fails", " - sunrpc: route to a populated pool in svc_pool_for_cpu()", " - svcrdma: Fix unmatched rn_unregister on failed accept", " - svcrdma: Reject connection when transport allocation fails", " - svcrdma: Reject inline replies that overflow the pull-up buffer", " - svcrdma: Validate Read chunk positions before reconstruction", " - udf: reject VAT indexes equal to the entry count", " - wifi: ath6kl: clamp assoc request/response lengths before subtracting IE", " offsets", " - staging: media: tegra-video: fix of_node_put() on VIP parse errors", " - staging: media: tegra-video: vi: fix probe failure on skipped last port", " - scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()", " - rpmsg: glink: smem: order FIFO read after availability check", " - arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck", " - arm64: dts: rockchip: Fix rk3399-roc-pc-plus analog audio", " - riscv: acpi: Handle LPI architectural context loss flags", " - remoteproc: scp: Fix device reference leak on failed lookup", " - qede: Fix NULL pointer dereference in TPA fragment processing", " - RDMA/cxgb4: Cancel reg_work before freeing device on remove", " - RDMA/ucma: Lock the handler in ucma_set_ib_path()", " - regulator: as3722_get_regulator_dt_data: fix premature of_node_put", " leaving dangling of_node pointer", " - regulator: max8998_pmic_dt_parse_pdata: of_node_put on reg_np after", " ownership transferred to rdata", " - regulator: qcom-refgen: correct the regulator type to CURRENT", " - ring-buffer: Free cpu_buffer::free_page with subbuf_order", " - ring-buffer: Hold cpu_buffer::lock when resizing a subbuf", " - orangefs: fix double-free of trailer_buf on readdir copy failure", " - orangefs: skip leading spaces before parsing client debug masks", " - ocfs2: always run deallocs on copy-on-write completion", " - ocfs2: bound namelen in dlm_migrate_request_handler", " - ocfs2: validate lengths in dlm_mig_lockres_handler", " - ocfs2: validate rl_used against rl_count in refcount block validator", " - ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from", " drop_item", " - ocfs2: cluster: fix o2hb_dependent_users leak on pin failure", " - ALSA: ump: Fix corrupted data bytes at MIDI 1.0 SysEx to UMP conversion", " - arm64: compat: Fix decrementing LDM/STM alignment emulation", " - ASoC: amd: yc: Add DMI entry for MSI Thin A15 B7UC", " - hwmon: (max6621) fix negative temperature offset and crit readings", " - hwmon: (max6621) fix temperature clamp range", " - nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error", " path", " - nvme-pci: disable controller on admin queue IRQ setup failure", " - sctp: distinguish sequence zero from wildcard in reconf lookup", " - power: supply: max17040: drop incorrect I2C functionality check", " - PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirk", " - PCI: meson: Fix GPIO state while requesting PERST#", " - PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608]", " - PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/MSI: Enable memory decoding before restoring MSI-X messages", " - PCI/proc: Avoid spurious runtime PM wakeup on config space accesses", " - PCI/proc: Use file_ns_capable() when checking config space read access", " - PCI/proc: Warn on writes to kernel-exclusive config space regions", " - iommu/arm-smmu-v3: Manage teardown with devm", " - iommu/vt-d: Fix no_iommu to disable platform opt-in", " - platform/x86: ISST: Just allow 2 bits for SST feature enable", " - platform/x86: ISST: Validate parameter for core power state", " - platform/x86: ISST: Validate parameter for frequency and priority", " - platform/x86: ishtp_eclite: Fix ACPI device reference leak in probe", " error path", " - platform/x86: hp-bioscfg: accept reduced ACPI packages from older HP", " BIOS", " - platform/x86: hp-bioscfg: advance elem past consumed array elements", " - platform/x86: hp-bioscfg: bound ordered-list parsing by the package", " count", " - platform/x86: hp-bioscfg: fix new_password_store() overwriting", " current_password", " - platform/x86: hp-bioscfg: fix ORD_LIST_ELEMENTS never being parsed", " - platform/x86: hp-bioscfg: warn on element type mismatch instead of", " failing", " - net: usb: qmi_wwan: add Telit Cinterion FE990D50 composition", " - platform/x86: ISST: Use PP level enable mask", " - platform/x86: ISST: Return error during profile addition", " - net: ipa: fix stalled modem TX queue after runtime resume", " - l2tp: improve tunnel/session refcount helpers", " - l2tp: use refcount_inc_not_zero in l2tp_session_get_by_ifname", " - net: openvswitch: fix nf_connlabels leak in ovs_ct_init", " - NTB: ntb_transport: Recycle TX entries before client callbacks", " - net: ntb_netdev: Avoid double-accounting netif_rx() drops", " - net: ntb_netdev: Count packets dropped on RX refill failure", " - net: fix spurious TX timeout after dev_activate()", " - iommu/amd: remove return value of amd_iommu_detect", " - PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip", " - arch_numa: avoid false positive fortify warning in", " setup_node_to_cpumask_map()", " - dm-switch: use WRITE_ONCE() in switch_region_table_write()", " - wifi: rtl8xxxu: remove rtl8xxxu_ prefix from filenames", " - [Config] Remove CRYPTO_DEV_SUN8I_SS_PRNG", " - [Config] Remove CRYPTO_DEV_SUN8I_CE_PRNG", " - wifi: rtl818x: initialize eeprom_93cx6 struct to zero", " - xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc()", " - sticon/parisc: Detect default STI graphics card for console output", " - signal: avoid shared siginfo namespace rewrites", " - taskstats: fix cpumask parsing cutting off the last character", " - timer: Keep debugobjects state consistent in migrate_timer_list()", " - udf: Fix i_lenExtents truncation on 32-bit kernels", " - platform/chrome: sensorhub: Fix dropped timestamp events and log spam", " - mm: avoid unnecessary use of is_swap_pmd()", " - mm: provide mm_struct and address to huge_ptep_get()", " - mm/rmap: use huge_ptep_get() in try_to_unmap_one()", " - Upstream stable to v6.6.149, v6.6.150, v6.6.151, v6.6.152, v6.6.153,", " v6.6.154, v6.6.155, v6.6.156, v6.12.102, v6.12.103, v6.12.104,", " v6.12.105, v6.12.106, v6.12.107, v6.12.108, v6.12.109", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80928", " - smack: fix cred UAF in smack_file_send_sigiotask()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80930", " - tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80931", " - w1: ds28e17: reject an oversize length on an I2C block read", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80932", " - vsock/virtio: flush works in dependency order", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80938", " - wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80941", " - wifi: rtw88: Fix potential memory leak in rtw_txq_push_skb()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80944", " - wifi: mwifiex: Detach sync cmd buffer on interrupted wait", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80834", " - crypto: sun8i-ce - Remove crypto_rng interface", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80833", " - crypto: sun8i-ss - Remove crypto_rng interface", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80947", " - wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80949", " - wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80951", " - i3c: master: svc: bound IBI payload to the requested max_payload_len", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80952", " - i3c: master: Fix info leak and UAF in device unregister path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80963", " - dm-stats: fix a crash if allocation of per-cpu data fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89771", " - ring-buffer: Fix subbuf resize race with ring buffer readers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80964", " - ALSA: virmidi: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80965", " - ALSA: serial-u16550: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80966", " - ALSA: portman2x4: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80967", " - ALSA: pcxhr: initialize mutexes before requesting threaded IRQ", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80968", " - ALSA: mts64: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80969", " - ALSA: mpu401: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80971", " - ALSA: bcd2000: clear the URB pointers on disconnect", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80972", " - ALSA: aloop: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80973", " - ALSA: 6fire: bound the MIDI event length from the device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80974", " - mfd: sm501: Fix potential memory leaks during remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80976", " - seg6: reset IP6CB after IPv6 decapsulation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80977", " - net: skbuff: don't touch shared zerocopy state in skb_tx_error()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80978", " - net: cap advertised IP tunnel headroom", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80979", " - net/smc: unregister the connection before draining the rx tasklet", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80982", " - net/smc: fix use-after-free in smc_rx_pipe_buf_release()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80983", " - net/smc: fix socket refcount leak in smc_switch_conns()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80984", " - net/smc: do not dereference an unset send buffer on the SMC-D teardown", " path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80987", " - NTB: ntb_transport: Reject oversized TX buffers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80988", " - NTB: ntb_transport: Fail TX enqueue when the QP link is down", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80989", " - net: thunderbolt: Mark the connection down when bringing it up fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80990", " - net: thunderbolt: Release the Rx HopID that was handed out on mismatch", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80991", " - net: ravb: serialize PTP clock teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80992", " - net: ravb: avoid dereferencing an invalid PTP clock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80994", " - net: openvswitch: fix flow mask use-after-free on flow deletion", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80996", " - net: l2tp: do not propagate multicast notification errors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80999", " - net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89439", " - platform/x86: ISST: Add a NULL check for sst_inst[]", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81000", " - net: tun: bound receive headroom", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81001", " - slip: fix use-after-free in sl_sync()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81002", " - xdp: fix zero-copy frame layout", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81003", " - net/iucv: filter frames in afiucv_hs_rcv() by ingress device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81005", " - ipmi: si: Fix NULL pointer dereference after failed registration", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81007", " - ipmi: ipmb: validate write message length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81008", " - interconnect: Fix use after free in icc_get() and of_icc_get_by_index()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81011", " - platform/x86: hp-bioscfg: pass validated element count to package", " parsers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81012", " - platform/x86: hp-bioscfg: fix off-by-one write in", " hp_get_string_from_buffer()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81013", " - platform/x86: hp-bioscfg: fix heap OOB read on empty password write", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81014", " - platform/x86: hp-bioscfg: fix heap OOB read in sk_store() and", " kek_store()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-81017", " - platform/chrome: sensorhub: Bound the EC-reported sensor number", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89438", " - platform/x86: ISST: Validate logical CPU id and clos id", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89440", " - mmc: via-sdmmc: stop card-detect handling on probe failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89442", " - platform/x86: ISST: Validate socket ID in clos_assoc ioctl", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89443", " - platform/x86: ISST: Validate level in perf mask ioctls", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89444", " - platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89448", " - iommu/vt-d: Force requesting ACS when tboot is enabled", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89451", " - iommu/sva: Set handle->dev before the SVA handle is visible", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89456", " - s390/dasd: Propagate partial completion length across ERP recovery", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89457", " - s390/dasd: Guard sysfs discipline callbacks against unallocated private", " data", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89458", " - s390/dasd: Do not complete a failed ESE read as successful", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89461", " - power: supply: max17040: synchronize work cancellation on suspend", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89462", " - power: supply: max17040: propagate register read errors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89463", " - power: supply: ucs1002: fix use-after-free on remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89464", " - power: supply: twl4030_charger: cancel workers via devm", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89465", " - power: supply: rt9455: quiesce delayed work before teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89466", " - power: supply: qcom_battmgr: terminate the strings from firmware", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89468", " - power: supply: lp8788-charger: fix use-after-free on remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89469", " - power: supply: lp8727: fix use-after-free in lp8727_release_irq()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89470", " - power: supply: cros_usbpd: Limit port counts to EC_USB_PD_MAX_PORTS", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89471", " - power: supply: cros_usbpd-charger: bound the EC-reported port count", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89472", " - power: supply: charger-manager: register regulators before exposing", " sysfs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89473", " - power: supply: bq25890: Fix power_supply reference leak", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89474", " - power: supply: bq256xx: drain usb_work before freeing the charger", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89475", " - power: supply: bq24257: fix use-after-free on remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89476", " - sctp: fix stream->outcnt underflow on duplicate RECONF responses", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89477", " - sctp: fix NULL deref on untransmitted RECONF completion", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89478", " - sctp: drop a chunk if its transport was removed", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89479", " - sctp: stop processing a packet once its association is deleted", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89480", " - nvme-tcp: reject a read that transferred too few bytes", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89481", " - nvme-tcp: fix host memory disclosure on R2T for a read command", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89482", " - nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89483", " - nvme: zero the discard fallback page", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89484", " - lockd: fix NULL dereference on lockowner allocation failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89485", " - lockd: pin next file across nlm_inspect_file lock-drop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89487", " - openvswitch: only skb_tx_error() a packet we are about to drop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89489", " - openrisc: fix arbitrary kernel memory access via or1k_atomic syscall", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89490", " - ocfs2: fix readdir position truncation on 32-bit kernels", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89491", " - ocfs2: cluster: don't sleep while holding o2hb_live_lock in", " o2hb_region_pin()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89567", " - jbd2: bound shrinker scans by examined checkpoint buffers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89532", " - svcrdma: Fix pcl_for_each_segment for empty chunks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89533", " - svcrdma: Fix offset arithmetic in read_chunk_range", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89536", " - SUNRPC: wait for in-flight client TLS handshake callback", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89538", " - SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89539", " - SUNRPC: reject duplicate CREDS_VALUE options", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89540", " - sunrpc: init gssp_lock before publishing proc entry", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89541", " - SUNRPC: harden gss_unwrap_resp_priv length checks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89542", " - SUNRPC: harden gss_krb5_unwrap_v2 against short tokens", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89547", " - SUNRPC: Check svc pool percpu counter allocation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89548", " - SUNRPC: always drain cache_cleaner before destroying a cache_detail", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89550", " - SUNRPC: svcauth_gss: enforce krb5 token minimum length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89551", " - SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89552", " - params: fix charp corruption on allocation failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89553", " - nouveau/gem: reserve the bo in the info ioctl around the vma lookup", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89554", " - mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89555", " - mpls: reload header after pskb_may_pull()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89557", " - md: do overflow check for sb->bblog_shift in super_1_load()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89559", " - libnvdimm/labels: Prevent integer overflow in __nd_label_validate()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89562", " - ip6_gre: fix hardware header length for NBMA tunnels", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89563", " - ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89569", " - Bluetooth: RFCOMM: serialize security confirmation handling", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80914", " - Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89573", " - dm array: reject an array block whose value size is not the caller's", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89574", " - dm array: validate array block headers on read", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89575", " - dm raid1: reserve space for NUL-terminator in build_constructor_string()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89576", " - dm-era: fix shadowed superblock leak on take-snap failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89579", " - bpf: Harden bloom filter sizing and indexing on 32-bit kernels", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89580", " - bpf: Disable preemption in __bpf_get_stack", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89582", " - bnx2x: fix double free in bnx2x_init_firmware() error path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89583", " - Bluetooth: eir: Fix OOB read in eir_get_service_data()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89585", " - auxdisplay: charlcd: cancel backlight work on registration failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89586", " - ata: libata-scsi: fix DSM TRIM for sector sizes larger than 2048 bytes", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89587", " - ACPI: pfr_update: fix stack buffer overflow in query_capability()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89588", " - ACPI: APEI: GHES: fix ARM section length accounting after header", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89594", " - hsi: omap_ssi_core: fix missing DMA mask setup for SSI controller device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89596", " - forcedeth: fix off-by-one when saving/restoring non-PCI config space", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89597", " - fbdev: uvesafb: unregister connector callback on init failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89598", " - fbdev: ssd1307fb: defer I2C transfers from damage callbacks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89599", " - fbdev: omapfb: panel-dsi-cm: initialize lock before registering display", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89604", " - efivarfs: Rate limit statfs() handler", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89605", " - ecryptfs: release message context on send failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89606", " - ecryptfs: reject too-small tag 70 packets", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89607", " - ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89608", " - ecryptfs: pass packet set buffer size to parser", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89609", " - ecryptfs: hold msg ctx list lock when cleaning daemon queue", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89615", " - fs/ntfs3: bound page_lcns[] index by the log record", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89616", " - fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89617", " - fs/ntfs3: validate dirty page table on log replay", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89618", " - eventfs: Initialize ei->children and ei->list in init_ei()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89621", " - HID: mcp2221: validate report size in mcp2221_raw_event()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89626", " - HID: sensor: custom: Fix field sysfs group cleanup on failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89627", " - HID: roccat: free buffered reports when destroying device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89628", " - HID: picolcd: clamp eeprom debugfs read to bytes actually received", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89634", " - smb: client: fix ALIGN() overflow in symlink_data() error context loop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89636", " - smb: client: clear ce->tgthint in free_tgts()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89640", " - cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89643", " - audit: avoid dropping live tree ref on fsnotify rule autoremove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89645", " - btrfs: drop recovered reloc root refs on recovery failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89647", " - ceph: do not repeat ceph_trim_dentries() if no progress possible", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89649", " - ceph: bound xattr value length in __build_xattrs()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89650", " - ceph: bound num_export_targets array for mds info v2/v3", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89652", " - ceph: bound copied dentry name length in NFS export get_name", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89653", " - ceph: reject export_targets ranks >= CEPH_MAX_MDS in mdsmap decode", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89655", " - ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89656", " - libceph: reject buckets with mismatched CRUSH ids", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89657", " - libceph: validate OSD extent maps before cursor advance", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89662", " - NFSD: Prevent lock owner use-after-free during client teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89663", " - nfsd: revoke copy-notify stateids before dropping their reference", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89665", " - nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89666", " - nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89669", " - nfsd: initialize copy-notify stateid before publishing it", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89671", " - nfsd: gate nfs3 setacl by argp->mask", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89672", " - nfsd: gate nfs2 setacl by argp->mask", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89674", " - nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89680", " - nfsd: fix nfsd_file leak on inter-server COPY setup failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89684", " - nfsd: fix cpntf publish race in nfs4_init_cp_state", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89686", " - nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation", " revoke", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89690", " - nfsd: defer vfree of compound ops to fix rpc_status UAF", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89691", " - nfsd: clear opcnt on compound arg release to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89694", " - nfsd: check client ownership when cancelling a copy-notify stateid", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89696", " - nfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89697", " - nfsd: add fh_want_write() for early-verified SETATTR in", " nfsd_proc_setattr()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89699", " - nfsd: validate symlink target length in NFSv4 CREATE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89702", " - nfsd: size fh_verify server sockaddr slot by xpt_locallen", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89704", " - nfsd: sample writeback error cursor before async COPY loop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89706", " - nfsd: Reset write verifier when async COPY writeback fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89707", " - nfsd: release path refs on follow_down() error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89710", " - NFSv4.1: fix layout segment leak on the pnfs_layout_process() forget", " path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89711", " - NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89712", " - NFSD: restart ssc_expire_umount walk after dropping nfsd_ssc_lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89713", " - NFSD: check truncate permission under inode lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89720", " - ubifs: fix out-of-bounds read in signature length check", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89723", " - nilfs2: fix slab-out-of-bounds in nilfs_direct_propagate after", " truncation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89724", " - media: vicodec: fix out-of-bounds write in FWHT encoder", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89725", " - media: cec: stm32: prevent out-of-bounds write on RX overflow", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89726", " - lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89729", " - HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89730", " - fpga: altera-cvp: Avoid out-of-bounds read in trailing byte write", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89732", " - usb: gadget: f_fs: Prevent deadlock during ep0 read loop", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89733", " - usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and", " uvc_function_unbind()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89735", " - usb: gadget: midi2: remove default configfs groups on teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89736", " - usb: gadget: u_audio: Fix use-after-free on sound card disconnect", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89738", " - usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89740", " - serial: imx: serialize imx_uart_ports[] lifetime", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89741", " - Revert \"media: v4l2-dev: fix error handling in", " __video_register_device()\"", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89742", " - rapidio: mport_cdev: fix use-after-free in dma_req_free()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89743", " - misc: nsm: bound the device-reported response length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89744", " - device property: fix infinite loop in fwnode_for_each_child_node()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89746", " - tracing: Fix use-after-free with same-name named triggers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89747", " - tracing: Fix use-after-free in trace_pipe read on sub-buffer order", " change", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89749", " - tracing: Fix crash passing ERR_PTR to kthread_stop()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89750", " - tracing/user_events: Clear copied tracing state before fork duplication", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89751", " - x86/tdx: Fix off-by-one in port I/O handling", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89752", " - mm: memcg: stop reclaim when a limit update is superseded", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89753", " - mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89756", " - mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89759", " - mm/kmemleak: avoid soft lockup when scanning task stacks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89761", " - apparmor: fix out-of-bounds write when null terminating a label vec", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89762", " - apparmor: fix cred UAF caused by begin_current_label_crit_section()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-89765", " - timers/itimer: Zero-init old itimerval before copy to userspace", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-53313", " - drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-53113", " - wifi: ath11k: fix memory leaks in beacon template setup", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-53102", " - wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-43344", " - perf/x86/intel/uncore: Fix die ID init and look up bugs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-38205", " - drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-21817", " - block: mark GFP_NOIO around sysfs ->store()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-22127", " - f2fs: fix potential deadloop in prepare_compress_overwrite()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-38621", " - md: make rdev_addable usable for rcu mode", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-22108", " - bnxt_en: Mask the bd_cnt field in the TX BD properly", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80825", " - wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80835", " - crypto: qcom-rng - Remove crypto_rng interface", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80922", " - crypto: qcom-rng - Allow zero as a random number", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80837", " - netfilter: nf_tables: don't queue packet path object notifications", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80838", " - vxlan: keep the last remote linked during FDB flush", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80839", " - batman-adv: reject unrepresentable multicast TVLV offsets", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80849", " - net/tcp-ao: fix use-after-free of current_key on reconnect to another", " peer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80850", " - tcp: fix AO info use-after-free in tcp_ao_connect_init()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80851", " - gtp: serialize PDP context updates", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80774", " - HID: asus: fix missing hid_is_usb() check", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80755", " - selinux: reject a permission value exceeding the class permission count", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80864", " - RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80771", " - HID: nintendo: register input device after capabilities are set", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40074", " - ipv4: start using dst_dev_rcu()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80820", " - xfs: don't livelock in scrub on a circular unlinked list", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74653", " - serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80815", " - ALSA: scarlett2: Use a private URB for the notification endpoint", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80727", " - x86/mce: Set up the polling timer before CMCI discovery", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74602", " - ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74684", " - net: tap: set skb->dev before parsing virtio net header in", " tap_get_user_xdp()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74483", " - binfmt_misc: don't leak the user namespace when the mount fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80556", " - mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80576", " - drm/amdgpu: reject oversized IBs with per-ring packet limits", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74590", " - fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74592", " - ima: Instantiate file_truncate and path_truncate hooks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74618", " - binfmt_misc: don't warn when the mount is completed from another user", " namespace", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74634", " - ring-buffer: Prevent subbuf order change when resizing is disabled", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64017", " - blk-mq: pop cached request if it is usable", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74677", " - net: usb: ipheth: fix carrier_work UAF on disconnect", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74710", " - xsk: require at least 16 bytes of TX metadata", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68266", " - drm/xe: Hold a dma-buf reference for imported BOs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74440", " - drm/xe: Wait on external BO kernel fences in exec IOCTL", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68273", " - drm/amdgpu: Fix context pstate override handling", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80704", " - drm/amd/display: use proper context for logging", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80711", " - power: supply: max17040: handle missing status supplier", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74484", " - binfmt_misc: don't let an 'F' entry pin its own instance", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74500", " - ALSA: usb-audio: fix stack info leak in RME Digiface status", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80689", " - tracing/mmiotrace: Add NULL check for mmio_trace_array in logging", " functions", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74535", " - Bluetooth: ISO: avoid deadlocks in iso_sock_timeout", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74536", " - Bluetooth: ISO: fix leaking sk after socket release", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80694", " - net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in", " poll_controller", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74543", " - net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80695", " - hwmon: (sht3x) Fix unaligned accesses", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74565", " - netfilter: nf_tables: make nft_object rhltable per table", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-72111", " - bpf: Reset register bounds before narrowing retval range in", " check_mem_access()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80824", " - usb: usbfs: fix use-after-free of usb_device in usbdev_release()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80826", " - USB: c67x00: fix use-after-free in c67x00_add_iso_urb()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80827", " - USB: serial: option: fix slab OOB read in interrupt URB callback", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80828", " - ALSA: usb-audio: Complete cleanup after system-resume errors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80829", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80830", " - usb: core: Add lock to usb_wakeup_notification()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80921", " - KVM: s390: vsie: zero stale crypto bits", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80831", " - crypto: mxs-dcp - fix source scatterlist length access", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80832", " - crypto: qce - fix CCM AAD buffer underallocation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80840", " - ipv6: seg6: clear IPv4 control block on IPIP decapsulation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80842", " - net: bridge: mcast: fix use-after-free of a master VLAN's multicast", " context", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80843", " - xfrm: fix xfrm_state_construct() auth-trunc leak", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80844", " - xfrm: ah6: validate routing header segments_left", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80846", " - xfrm: drop ESP-in-TCP packets with no ingress device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80848", " - xfrm: espintcp: fix UAF during close", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80852", " - tls: device: fix out-of-bounds write in tls_append_frag()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80854", " - usb: gadget: f_tcm: keep port count until LUN teardown completes", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80855", " - fuse: fix invalidate lock leak on open O_TRUNC DAX failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80856", " - fuse: fix invalidate lock leak on setattr writeback failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80923", " - xhci: dbgtty: Fix unregister on tty_register_driver() failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80762", " - Bluetooth: hci_sync: Fix accept list UAF during suspend", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80780", " - HID: pidff: fix OOB write when hid->inputs is empty", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80766", " - HID: uclogic: fix use-after-free of inrange_timer on remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80768", " - HID: ft260: fix stack-use-after-return write in I2C read race", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80770", " - HID: nintendo: stop device IO before hid_hw_stop on probe failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80789", " - nvmet-tcp: bound SGL data length before allocating command buffers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80783", " - HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80796", " - nfc: nci: add data_len bound checks to activation parameter extractors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80807", " - nilfs2: reject invalid block index in GC ioctl", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64070", " - powerpc/hv-gpci: fix preempt count leak in sysfs show paths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64082", " - riscv: Fix register corruption from uninitialized cregs on error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-53089", " - bpf: Fix use-after-free in offloaded map/prog info fill", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-45963", " - ASoC: nau8821: Cancel delayed work on component remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40168", " - smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40139", " - smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40102", " - KVM: arm64: Prevent access to vCPU events before init", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40064", " - smc: Fix use-after-free in __pnet_find_base_ndev().", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-39925", " - can: j1939: implement NETDEV_UNREGISTER notification handler", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-39833", " - mISDN: hfcpci: Fix warning when deleting uninitialized timer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-38237", " - media: platform: exynos4-is: Add hardware sync wait to", " fimc_is_hw_change_mode()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-38206", " - exfat: fix double free in delayed_free", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-38203", " - jfs: Fix null-ptr-deref in jfs_ioc_trim", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-22104", " - ibmvnic: Use kernel helpers for hex dumps", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2024-58095", " - jfs: add check read-only before txBeginAnon() call", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2024-58094", " - jfs: add check read-only before truncation in jfs_truncate_nolock()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80806", " - ext4: don't enable DAX on new encrypted files", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80863", " - RDMA/rxe: Fix OOB in free_rd_atomic_resources()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80590", " - inet: frags: strip GSO state from fragments before reassembly", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80763", " - Bluetooth: hci_event: validate LE Set CIG Parameters response", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80764", " - Bluetooth: hci_event: fix LE list UAF on reset", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80765", " - HID: hyperv: validate initial device info bounds", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80767", " - HID: sensor: custom: Fix use-after-free in enable_sensor", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80918", " - HID: core: fix number/pointer type confusion on long items", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80772", " - HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80784", " - mptcp: pm: fix memory leak from alloc-during-teardown race", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74509", " - Bluetooth: hci_sync: Fix advertising data UAFs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64581", " - xfrm: fix sk_dst_cache double-free in xfrm_user_policy()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80781", " - HID: core: fix OOB read of field->usage in hid_set_field()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80782", " - HID: magicmouse: do not keep a stale msc->input if no input is claimed", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80583", " - ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80581", " - ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC", " timeout", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80788", " - nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80790", " - nvmet-fc: fix invalid free in LS IOD error path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80791", " - nvmet-auth: zero the AUTH_RECEIVE response buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80792", " - ipv6: fix use-after-free in ip6_finish_output2()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80793", " - ipv4: reject undersized MTUs in ip_do_fragment()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80557", " - libceph: fix OOB read in decode_watchers() via missing bounds check", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80572", " - Input: byd - synchronize timer deletion before freeing private data", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80794", " - nfc: nci: fix uninit-value in the RF discover/activated NTF handlers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80795", " - nfc: nci: fix out-of-bounds write in nci_target_auto_activated()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80823", " - nfc: st21nfca: validate ATR_REQ length against the received frame", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80797", " - nfc: pn533: purge fragmented skbs during cleanup", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80798", " - nfc: llcp: reject PDUs shorter than the LLCP header", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80799", " - nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80800", " - nfc: llcp: bound the connect_sn TLV walk to the skb", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80801", " - nfc: microread: validate target discovery payload lengths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80802", " - nfc: fdp: bound the device-reported read length and fix an skb leak", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80803", " - nfc: digital: clamp SENSF_RES length to the destination buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80547", " - s390/vfio_ccw: Implement a crw lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80551", " - s390/vfio_ccw: Ensure first IDAW remains constant", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80555", " - s390/vfio_ccw: Free all memory if cp_init() fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80562", " - gpio: ml-ioh: use raw_spinlock_t for the register lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80805", " - xfs: validate attr entry pointer before field access", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80808", " - ext4: stop retrying saturated xattr cache entries", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80916", " - kcov: fix data corruption and race conditions on PREEMPT_RT", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80809", " - ocfs2: fix missing metadata reservation for large xattrs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80812", " - ALSA: dummy: Check card index validity at probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80536", " - xfs: bounds-check buffer log item's dirty bitmap", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74662", " - inet: frags: publish queues before arming timer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74655", " - serial: qcom-geni: fix TX DMA buffer flush", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74637", " - perf/core: Fix group leader use-after-free after sibling detach", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80737", " - serial: amba-pl011: synchronize DMA teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74626", " - NTB: ntb_netdev: Preserve RX queue depth on allocation failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80814", " - rndis_host: add overflow check in rndis_rx_fixup()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80819", " - Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80917", " - PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74601", " - ring-buffer: Use current_context for safe per-CPU buffer swap", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74628", " - net/x25: fix use-after-free of the socket by its timers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74736", " - net/sched: cls_bpf: reject dev-bound programs bound to a different", " device", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74737", " - net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74739", " - net/sched: cls_u32: skip hash tables in u32_bind_class()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74740", " - net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80742", " - af_packet: Don't send zero-byte data in tpacket_snd().", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80743", " - ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80904", " - net/tls: Fail tls_sw_splice_read() after a failed async decrypt", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80906", " - net: packet: fix wrong transport_header when sending VLAN-tagged frame", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74743", " - macvlan: inherit needed_headroom and needed_tailroom from lowerdev", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74744", " - ipvlan: inherit needed_headroom and needed_tailroom from phy_dev", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74746", " - netfilter: flowtable: publish GC-visible tuple last", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80744", " - netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort", " path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74748", " - netfilter: ipset: fix refcount race between list:set GC and swap", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74632", " - mm/huge_memory: fix huge_zero_pfn race", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74607", " - KVM: SVM: Serialize accesses to the owner and mirror list with separate", " lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74599", " - mm/ptdump: always stabilise against page table freeing using init_mm", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74672", " - mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74450", " - drm/amd/pm: fix pptable use-after-free", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74474", " - vxlan: use pskb_network_may_pull() for transmit path header pulls", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74487", " - binfmt_misc: restore write access when removing an entry", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74476", " - veth: convert frag_list skbs before running XDP", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74479", " - net: pktgen: fix proc entry use-after-free", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74494", " - ksmbd: reject repeated SMB2 NEGOTIATE requests", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80715", " - igc: remove napi_synchronize() in igc_down()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80526", " - ASoC: tas2562: Validate values for volume writes", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80686", " - mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68118", " - tcp: challenge ACK for non-exact RST in SYN-RECEIVED", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68431", " - ksmbd: validate minimum PDU size for transform requests", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68132", " - super: fix emergency thaw deadlock on frozen block devices", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68138", " - net/sched: serialize qdisc_rtab_list against concurrent get/put", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68082", " - libceph: fix two unsafe bare decodes in decode_lockers()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68166", " - userfaultfd: prevent registration of special VMAs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68159", " - libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80527", " - ceph: fix hanging __ceph_get_caps() with stale mds_wanted", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80528", " - ceph: avoid fs reclaim while using current->journal_info", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80529", " - xfs: don't swallow dquot recovery verification errors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80534", " - xfs: fix ilock leak on error in xfs_dq_get_next_id", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80539", " - drm/amdgpu: disallow multiple FENCE chunks in one submit", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80540", " - drm/amdgpu: Fix UVD decode image min size calculation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80907", " - drm/amdgpu: Fix UVD dpb min size calculation for H264", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80908", " - drm/amdgpu: Reject UVD message with dimensions above 4096", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80541", " - drm/amdgpu: validate GEM_CREATE domain combinations", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80909", " - drm/amdgpu: Reject UVD message with invalid number of h265 refs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80548", " - s390/vfio_ccw: Selectively expand io_mutex", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80549", " - s390/vfio_ccw: Move cp cleanup out of not operational", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80550", " - s390/vfio_ccw: Fix out of bounds check on CCW array", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80552", " - s390/vfio_ccw: Ensure index for read/write regions are within range", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80553", " - s390/vfio_ccw: Cancel existing workqueues", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80554", " - s390/vfio_ccw: Limit the number of channel program segments", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80558", " - libceph: Avoid using invalid osd indices from primary_temp", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80559", " - Input: sur40 - fix input device registration ordering", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80560", " - openrisc: signal: do not restore privileged SR bits on sigreturn", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80561", " - libceph: fix multiple unsafe decodes in decode_locker()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80565", " - crypto: qce - fix error path in devm_qce_register_algs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80566", " - Input: hynitron_cstxxx - validate touch count and finger IDs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80567", " - Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80568", " - Input: synaptics-rmi4 - block s_input when F54 queue is busy", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80569", " - Input: synaptics-rmi4 - bound the F54 report size to the allocated", " buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80570", " - Input: synaptics-rmi4 - zero report size on F54 work error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80573", " - Input: iforce - validate input packet lengths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80752", " - Input: psxpad-spi - set driver data before use", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80574", " - Input: focaltech - fix array out-of-bounds in", " focaltech_process_rel_packet", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80754", " - Input: synaptics-rmi4 - fix F55 transmitter electrode count typo", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80578", " - fbdev: core: Fix pointer desynchronization in fb_io_read()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80910", " - ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80911", " - ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80584", " - s390/qeth: validate user buffer length in SNMP and ARP query ioctls", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80585", " - mptcp: fastopen: only mark MPTFO subflows with SYN data", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80586", " - mptcp: options: reset DSS fields in case of unexpected size", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80587", " - mptcp: avoid combining some incoming suboptions", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80912", " - selinux: reject an unclaimed class value in security_get_classes()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80756", " - selinux: do not cancel a policy conversion that never started", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80757", " - selinux: reject a class permission count below its inherited common", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80913", " - selinux: require every boolean value to be defined", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2025-40054", " - f2fs: fix UAF issue in f2fs_merge_page_bio()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80589", " - block: stop the timeout timer when releasing a never added disk", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74585", " - thunderbolt: Bound the DROM dual link port number before indexing", " sw->ports", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74586", " - sctp: clear new_transport when removing a peer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74587", " - sctp: fix use-after-free of cached ASCONF chunk", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74588", " - sctp: keep chunk->transport in step with the list it is queued on", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74589", " - bpf, sockmap: Fix sk_redir use-after-free in send verdict", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74594", " - sched/psi: Shut down rtpoll_timer in psi_cgroup_free()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74595", " - fscrypt: use the mount idmap for the owner check in", " fscrypt_ioctl_set_policy()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74597", " - ip6_tunnel: clear skb2->cb[] in ip6ip6_err()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74598", " - ipv6: fix Route Information option length validation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74603", " - ptp: ocp: Fix board ID over-read", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74604", " - Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\"", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74606", " - eventfs: Fix use-after-free in eventfs_remove_rec()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80726", " - KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow", " page", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74608", " - smb: client: Fix use-after-free in cifs_try_adding_channels()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74609", " - tipc: read le->link under the node lock in tipc_node_link_down()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74610", " - tls: don't leave a full plaintext sk_msg ring unpushed", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74580", " - vhost: reset the vring metadata cache on vring reconfiguration", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74612", " - veth: fix skb length accounting after XDP frag adjustment", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74613", " - vsock/virtio: avoid refilling the RX queue after teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74614", " - vsock/virtio: read virtqueues under worker locks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74615", " - vxlan: do not arm the ageing timer on a device that is down", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74616", " - xdp: reject clones that overrun skb_shared_info tailroom", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74619", " - ovl: don't warn when the mount is completed from another user namespace", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74620", " - net/sched: act_gact, act_police: range check the fallback control action", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74621", " - net/sched: act_ct: fix sk_buff leak when the header checks reject a", " packet", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74622", " - net: atlantic: free RX pages of consumed but not refilled buffers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74623", " - net: atlantic: free stranded TX buffers on ring deinit", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74624", " - netfilter: nf_conntrack: defer invalid log until after unlock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74625", " - netfilter: bridge: release template ct on non-IP path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74630", " - ipv6: prevent in6_dev_get() from resurrecting inet6_dev", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74631", " - net: smc: fix splice entry lifetime imbalance in smc_rx_splice", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74635", " - fbdev: bitblit: bound-check glyph index in bit_cursor()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74636", " - tracing: Fix race between update_event_fields and, event_define_fields", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74641", " - ALSA: usx2y: bound the hwdep mmap fault offset", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80730", " - ring-buffer: Fix crash passing ERR_PTR to kthread_stop()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74646", " - misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74647", " - misc: fastrpc: Remove buffer from list prior to unmap operation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74648", " - staging: rtl8723bs: validate monitor transmit frame lengths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74649", " - staging: rtl8723bs: fix missing shared-key auth challenge length check", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74650", " - staging: rtl8723bs: fix OOB read in WMM_param_handler()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74651", " - staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74654", " - serial: 8250_dma: Clear stale RX state on shutdown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74656", " - ipv4: fix use-after-free in fib_nhc_update_mtu()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74657", " - ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74658", " - futex: Prevent robust futex exit race some more", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74514", " - KVM: s390: pci: Fix memory accounting for pinned/unpinned pages", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74659", " - net: bridge: mrp: fix uninitialised bytes on the wire", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74660", " - netfilter: ebt_nflog: pin the NFLOG backend", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74661", " - mac802154: fix netdev use-after-free in beacon worker", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80731", " - net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74663", " - net/sched: reject overly deep qdisc hierarchies", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74664", " - net: openvswitch: reallocate update replies for mismatched IDs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74666", " - packet: synchronize pressure clearing with ring reconfiguration", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74667", " - net/packet: reset the MAC header on the packet-socket transmit path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74668", " - packet: use consistent hard_header_len in TX_RING send path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74582", " - packet: use consistent hard_header_len in non-ring send paths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74669", " - ipvs: clear IPv4 options after rebasing tunnel ICMP errors", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74670", " - ipvs: stop estimator after disabled calc phase", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74671", " - ima: fix out-of-bounds read in xattr_verify()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74673", " - Input: evdev - fix information leak in evdev_pass_values()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74675", " - vt: stabilize tty reference in kbd_keycode with tty_port_tty_get", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74676", " - vt: add permission check for KDSKBMETA ioctl", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74678", " - net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74679", " - usb: gadget: f_ncm: Use unsigned int for ndp_index", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74680", " - usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74682", " - ALSA: usb-audio: fix OOB write on Type II inbound URBs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74683", " - Input: evdev - sanitize event type index when fetching event masks", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74688", " - sctp: clear control chunk transport if it is being removed", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74689", " - net/atm: fix slab-out-of-bounds read in vcc_setsockopt()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80732", " - ata: pata_sl82c105: fix bridge revision use-after-free", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74691", " - net: thunderbolt: Tear down DMA paths before stopping the rings", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74692", " - net/smc: fix TOCTOU race between smc_listen_out() and listener close", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80733", " - net: remove WARN_ON_ONCE() from sk_mc_loop()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74693", " - net: prestera: validate firmware header length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74694", " - net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74696", " - tcp: fix TFO max_qlen accounting across reuseport migration", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74697", " - bnxt_en: Disable EOP for TPA on all chips to prevent data corruption", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74700", " - net/sched: cls_api: Always acquire rtnl_lock when destroying locked", " classifiers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74701", " - net/openvswitch: check Ethernet header length in key_extract()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74704", " - net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74705", " - udp: fix potential use-after-free in tunnel segmentation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74714", " - bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74717", " - net/mlx5: fw_tracer, return NULL on create error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74718", " - devlink: fix net namespace reference leak in reload", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74583", " - net/sched: cls_route: fix fastmap use-after-free on filter", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74719", " - net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in", " smc_llc_event_handler()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74720", " - bpf: Preserve pointer state for commuted arithmetic", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74722", " - btrfs: fix memory leak in btrfs_do_encoded_write()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74724", " - ipvs: avoid out-of-bounds write in ip_vs_nat_icmp", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80739", " - net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74726", " - bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74730", " - NFS: Pin the 'struct nfs_server' during a FREE_STATEID call", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80708", " - s390/zcrypt: Fix missing mem scrub at clear key import in", " cca_clr2cipherkey()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68253", " - drm/i915/hdcp: check streams[] bounds before overflow", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68169", " - mptcp: pm: userspace: fix use-after-free in get_local_id", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64586", " - wifi: brcmfmac: drain bus_reset work on device removal", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68198", " - wifi: ath6kl: fix use-after-free in aggr_reset_state()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68254", " - drm/i915/vrr: require valid min/max vfreq for VRR", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74441", " - usb: typec: ucsi: Fix race condition and ordering in port unregistration", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68367", " - usb: gadget: f_tcm: synchronize delayed set_alt with teardown", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74468", " - gpio: pch: use raw_spinlock_t for the register lock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74482", " - mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80893", " - mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80700", " - drm/vmwgfx: validate external BO copy bounds for both stride paths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80887", " - drm/vmwgfx: use check_add_overflow for shader size+offset bound", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74443", " - drm/vmwgfx: bound DMA command body size against suffix pointer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74444", " - drm/vmwgfx: validate DRAW_PRIMITIVES header size before division", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80888", " - drm/vmwgfx: drop dma_buf reference on foreign-fd prime import", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74445", " - drm/vmwgfx: reject DX_BIND_QUERY without a DX context", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80702", " - drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74446", " - drm/amdkfd: hold event_mutex while checkpointing CRIU events", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74448", " - drm/amdkfd: fix QID bit leak in pqm_create_queue()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80703", " - drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74453", " - drm/vc4: Zero the tile state data array before each BIN job", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74454", " - drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO", " size", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74455", " - can: peak_usb: validate uCAN receive record lengths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74456", " - can: peak_usb: peak_usb_start(): fix double free of transfer buffer on", " URB submit error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74457", " - can: peak_usb: add bounds check for USB channel index", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80706", " - can: softing: fw_parse(): validate firmware record spans", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74458", " - can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received", " command extents", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80707", " - can: j1939: transport: j1939_session_fresh_new(): initialize receive", " buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74459", " - can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB", " resubmit failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74460", " - can: ems_usb: validate CPC message lengths", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74461", " - i2c: imx: Cancel hrtimer before clearing slave pointer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80678", " - i2c: imx: Fix slave registration race and error handling", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74463", " - i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock", " deadlock", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74464", " - net: openvswitch: fix skb leak on flow key update failure during ct", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74465", " - net: openvswitch: fix potential UAF on meter attach failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68451", " - s390/zcrypt: Validate length for CCA ECC private key requests", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68452", " - s390/zcrypt: Validate length for CCA AES cipher key requests", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80709", " - s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80710", " - s390/dasd: Fix undersized format-check buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80679", " - s390/dasd: Fix potential NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74467", " - s390/qeth: Check CAP_NET_ADMIN for private ioctls", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80680", " - i2c: amd-mp2: Unregister callback on adapter add failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74469", " - sctp: prevent peer transport count overflow", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80890", " - sctp: reject stale cookies with mismatched verification tags", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74470", " - scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74471", " - tracing: Check return value of __register_event() in", " trace_module_add_events()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74472", " - ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74473", " - vxlan: use pskb_network_may_pull() in route_shortcircuit()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74475", " - vxlan: use neigh_ha_snapshot() in route_shortcircuit()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80681", " - vxlan: re-fetch eth header after route_shortcircuit()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74478", " - um: vector: fix use-after-free in vector_mmsg_rx()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74581", " - net: ipv6: clear suppressed fib6 rule result", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74480", " - net: bridge: stop fast-leave after deleting a port group", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74481", " - mm/page_reporting: use system_freezable_wq to fix UAF during suspend", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74485", " - binfmt_misc: reject a flag character as the field delimiter", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74488", " - wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74490", " - tipc: avoid use-after-free in poll trace queue dumps", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74492", " - netfilter: ipset: do not update comments from kernel-side hash adds", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74493", " - net/smc: fix socket use-after-free during link group termination", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80714", " - ipvs: do not propagate one-packet flag to synced conns", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74495", " - igbvf: Fix leak in TX DMA error cleanup", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74497", " - ALSA: usb-audio: Clamp frame size in implicit-feedback mode", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74498", " - ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74499", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74501", " - ALSA: usb-audio: fix use-after-free in ump_to_endpoint()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74502", " - ALSA: ump: fix double free of out_cvts on rawmidi error", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80716", " - ALSA: pcm: wake linked drain waiters on unlink", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74505", " - ALSA: 6fire: Fix UAF at error handling during probe", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74507", " - Bluetooth: HIDP: validate numbered report payloads", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74508", " - Bluetooth: HIDP: reject frames without a transaction header", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74510", " - Bluetooth: mgmt: fix UAF in pair command cancellation", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74512", " - audit: fix potential use-after-free in audit_del_rule()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80717", " - sctp: validate Adaptation Indication parameter length", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80891", " - KVM: s390: pci: Validate AIBV and AISB before pinning guest pages", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80684", " - KVM: s390: pci: Fix NULL dereference on AIBV allocation failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74515", " - KVM: s390: pci: Reject adapter interrupt forwarding if already enabled", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74516", " - KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is", " active", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74518", " - mm/hugetlb: fix list corruption in allocate_file_region_entries()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80718", " - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80892", " - erofs: cap LZMA stream pool size", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74519", " - pinctrl: devicetree: don't free uninitialized dev_name on error path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74522", " - ksmbd: fix use-after-free in __close_file_table_ids()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74523", " - qede: sync udp_tunnel ports outside qede_lock in the recovery path", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74525", " - net: sxgbe: free TX rings on RX allocation failure", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80691", " - scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74531", " - Bluetooth: hci_conn: hold conn reference in abort_conn_sync()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74532", " - Bluetooth: btintel: Validate length before parsing diagnostics TLV", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74540", " - Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74541", " - Bluetooth: ISO: clear iso_data always when detaching conn from hcon", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80722", " - wifi: mac80211: validate individual TWT params before driver setup", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74546", " - hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74547", " - hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74548", " - forcedeth: fix UAF of txrx_stats in nv_remove", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74549", " - hwmon: (nct6775-core) Prevent access to unsupported weight registers", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74550", " - net: do not send ICMP/NDISC Redirects when peer allocation fails", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74551", " - hwmon: (nzxt-smart2) DMA-align output buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74552", " - hwmon: (lm90) Only report alarms if driver is ready", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74553", " - hwmon: (nct6775-core) Fix number of temperature registers for NCT6116", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74555", " - scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74556", " - scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection", " buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74557", " - scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74563", " - rds: tcp: hold the RCU lock across ipv6_chk_addr() in", " rds_tcp_laddr_check()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74579", " - netfilter: nft_payload: fix mask build for partial field offload", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80901", " - ipvs: fix the checksum validations", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74564", " - netfilter: xt_hashlimit: validate hashtable supports", " XT_HASHLIMIT_RATE_MATCH", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74566", " - keys: make keyring key-chunk byte order agree with", " keyring_diff_objects()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74567", " - keys: fix out-of-bounds read in keyring_get_key_chunk()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74569", " - netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in", " sip_help_tcp()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74572", " - btrfs: zoned: fix deadlock between metadata writeback and transaction", " commit", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74574", " - dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-80902", " - dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74575", " - thunderbolt: Prevent XDomain delayed work use-after-free on disconnect", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-74577", " - net: mpls: initialize rtm_tos in mpls_getroute()", "", " * Noble update: upstream stable patchset 2026-10-05 (LP: #2169770) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", "", " * Miscellaneous upstream changes", " - sd", "" ], "package": "linux", "version": "6.8.0-148.148", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2170052, 1786013, 2169329, 2131181, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169853, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169822, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770, 2169770 ], "author": "Mehmet Basaran ", "date": "Fri, 09 Oct 2026 18:11:01 +0300" } ], "notes": "linux-modules-6.8.0-149-generic version '6.8.0-149.149' (source package linux version '6.8.0-149.149') was added. linux-modules-6.8.0-149-generic version '6.8.0-149.149' has the same source package name, linux, as removed package linux-modules-6.8.0-147-generic. As such we can use the source package version of the removed package, '6.8.0-147.147', 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-image-6.8.0-147-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "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-6.8.0-147-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "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 24.04 noble image from daily image serial 20261105 to 20261107", "from_series": "noble", "to_series": "noble", "from_serial": "20261105", "to_serial": "20261107", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }