{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-136-generic", "linux-modules-6.8.0-136-generic" ], "removed": [ "linux-image-6.8.0-134-generic", "linux-modules-6.8.0-134-generic" ], "diff": [ "linux-image-virtual", "tar" ] } }, "diff": { "deb": [ { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-134.134", "version": "6.8.0-134.134" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-136.136", "version": "6.8.0-136.136" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-136.136", "" ], "package": "linux-meta", "version": "6.8.0-136.136", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Wed, 01 Jul 2026 22:50:03 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-135.135", "" ], "package": "linux-meta", "version": "6.8.0-135.135", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Sat, 27 Jun 2026 03:32:55 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-132.133", "" ], "package": "linux-meta", "version": "6.8.0-132.133", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Sun, 21 Jun 2026 17:39:56 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-132.132", "" ], "package": "linux-meta", "version": "6.8.0-132.132", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Sat, 20 Jun 2026 20:13:56 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "tar", "from_version": { "source_package_name": "tar", "source_package_version": "1.35+dfsg-3ubuntu0.2", "version": "1.35+dfsg-3ubuntu0.2" }, "to_version": { "source_package_name": "tar", "source_package_version": "1.35+dfsg-3ubuntu0.3", "version": "1.35+dfsg-3ubuntu0.3" }, "cves": [ { "cve": "CVE-2026-5704", "url": "https://ubuntu.com/security/CVE-2026-5704", "cve_description": "A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2160650 ], "changes": [ { "cves": [ { "cve": "CVE-2026-5704", "url": "https://ubuntu.com/security/CVE-2026-5704", "cve_description": "A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.", "cve_priority": "medium", "cve_public_date": "2026-04-06 16:16:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Extract files issue", " - debian/patches/CVE-2026-5704-*.patch: address a regression", " that makes valid files not extract in src/list.c,", " tests/Makefile.am, tests/extrac32.at, tests/extrac34.at,", " test/testsuite.at, src/extract.c, tests/extract23,", " tests/extrac30.at (LP: #2160650).", "" ], "package": "tar", "version": "1.35+dfsg-3ubuntu0.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2160650 ], "author": "Leonidas Da Silva Barbosa ", "date": "Wed, 15 Jul 2026 08:35:09 -0300" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-136-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-134.134", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-136.136", "version": "6.8.0-136.136" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-136.136", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-136.136", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Wed, 01 Jul 2026 22:50:28 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-135.135", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-135.135", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Sat, 27 Jun 2026 03:34:33 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-132.133", "" ], "package": "linux-signed", "version": "6.8.0-132.133", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Sun, 21 Jun 2026 17:40:33 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-132.132", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-132.132", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Sat, 20 Jun 2026 20:14:22 +0300" } ], "notes": "linux-image-6.8.0-136-generic version '6.8.0-136.136' (source package linux-signed version '6.8.0-136.136') was added. linux-image-6.8.0-136-generic version '6.8.0-136.136' has the same source package name, linux-signed, as removed package linux-image-6.8.0-134-generic. As such we can use the source package version of the removed package, '6.8.0-134.134', 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-136-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-134.134", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-136.136", "version": "6.8.0-136.136" }, "cves": [ { "cve": "CVE-2026-46117", "url": "https://ubuntu.com/security/CVE-2026-46117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46314", "url": "https://ubuntu.com/security/CVE-2026-46314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject empty multisync extension to prevent infinite loop v3d_get_extensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL; The guard never fires because v3d_get_multisync_post_deps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely. Fix this by rejecting a multisync extension where both in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-31707", "url": "https://ubuntu.com/security/CVE-2026-31707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate response sizes in ipc_validate_msg() ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t); resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply. A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length. Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX. The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed. This is the response-side analogue of aab98e2dbd64 (\"ksmbd: fix integer overflows on 32 bit systems\"), which hardened the request side.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46068", "url": "https://ubuntu.com/security/CVE-2026-46068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31613", "url": "https://ubuntu.com/security/CVE-2026-31613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB reads parsing symlink error response When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server. symlink_data() walks SMB 3.1.1 error contexts with the loop test \"p < end\", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits. smb2_parse_symlink_response() then bounds-checks the substitute name using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from iov_base. That value is computed as sizeof(smb2_err_rsp) + sizeof(smb2_symlink_err_rsp), which is correct only when ErrorContextCount == 0. With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iov_len. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2). Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset. Because sub_offs and sub_len are 16bits, the pointer math will not overflow here with the new greater-than.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43245", "url": "https://ubuntu.com/security/CVE-2026-43245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs: ->d_compare() must not block ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45845", "url": "https://ubuntu.com/security/CVE-2026-45845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: fix NULL pointer dereference in class dump When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference. The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478) Call Trace: tc_fill_tclass (net/sched/sch_api.c:1966) qdisc_class_dump (net/sched/sch_api.c:2326) taprio_walk (net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc (net/sched/sch_api.c:2352) tc_dump_tclass_root (net/sched/sch_api.c:2370) tc_dump_tclass (net/sched/sch_api.c:2431) rtnl_dumpit (net/core/rtnetlink.c:6864) netlink_dump (net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg (net/core/rtnetlink.c:6959) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Fix this by substituting &noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks. Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics. After this change *old can be a valid qdisc, NULL, or &noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46207", "url": "https://ubuntu.com/security/CVE-2026-46207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix empty payload in tap skb for non-linear buffers For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized. Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb(). While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46164", "url": "https://ubuntu.com/security/CVE-2026-46164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info_sub_group() error path When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46201", "url": "https://ubuntu.com/security/CVE-2026-46201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() When xe_dma_buf_init_obj() fails, the attachment from dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before returning the error. Note: we cannot use goto out_err here because xe_dma_buf_init_obj() already frees bo on failure, and out_err would double-free it. (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46211", "url": "https://ubuntu.com/security/CVE-2026-46211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata() msm_ioctl_gem_info_get_metadata() always returns 0 regardless of errors. When copy_to_user() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not. Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copy_to_user() call. Add the missing NULL check for kmemdup() and return ret instead of 0. Note that the SET counterpart (msm_ioctl_gem_info_set_metadata) correctly returns ret. Patchwork: https://patchwork.freedesktop.org/patch/714478/", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46200", "url": "https://ubuntu.com/security/CVE-2026-46200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix controller deregistration Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and gpios during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46241", "url": "https://ubuntu.com/security/CVE-2026-46241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on registration failure Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-23171", "url": "https://ubuntu.com/security/CVE-2026-23171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix use-after-free due to enslave fail after slave array update Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems. It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummy Then run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp \"dp=1-1023, flags=syn\" The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46111", "url": "https://ubuntu.com/security/CVE-2026-46111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in create_big_sync Add hci_conn_valid() check in create_big_sync() to detect stale connections before proceeding with BIG creation. Handle the resulting -ECANCELED in create_big_complete() and re-validate the connection under hci_dev_lock() before dereferencing, matching the pattern used by create_le_conn_complete() and create_pa_complete(). Keep the hci_conn object alive across the async boundary by taking a reference via hci_conn_get() when queueing create_big_sync(), and dropping it in the completion callback. The refcount and the lock are complementary: the refcount keeps the object allocated, while hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on hdev->conn_hash, as required by hci_conn_del(). hci_conn_put() is called outside hci_dev_unlock() so the final put (which resolves to kfree() via bt_link_release) does not run under hdev->lock, though the release path would be safe either way. Without this, create_big_complete() would unconditionally dereference the conn pointer on error, causing a use-after-free via hci_connect_cfm() and hci_conn_del().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46199", "url": "https://ubuntu.com/security/CVE-2026-46199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46204", "url": "https://ubuntu.com/security/CVE-2026-46204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46218", "url": "https://ubuntu.com/security/CVE-2026-46218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add bounds checking to ib_{get,set}_value The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46229", "url": "https://ubuntu.com/security/CVE-2026-46229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels. The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers. This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46225", "url": "https://ubuntu.com/security/CVE-2026-46225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: rspi: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46226", "url": "https://ubuntu.com/security/CVE-2026-46226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46235", "url": "https://ubuntu.com/security/CVE-2026-46235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: add ioremap return checks and cleanups Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46312", "url": "https://ubuntu.com/security/CVE-2026-46312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops. gst-launch-1.0 v4l2src ! gtk4paintablesink [ 38.201528] ------------[ cut here ]------------ [ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [ 38.219040] Tainted: [W]=WARN [ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp : ffffc0008dc678e0 [ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [ 38.231488] Call trace: [ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [ 38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813] __mmap_region+0x488/0x9a0 [ 38.233277] mmap_region+0xd0/0x148 [ 38.233703] do_mmap+0x350/0x5c0 [ 38.234148] vm_mmap_pgoff+0x14c/0x200 [ 38.234612] ksys_mmap_pgoff+0x150/0x208 [ 38.235107] __arm64_sys_mmap+0x34/0x50 [ 38.235611] invoke_syscall+0x50/0x120 [ 38.236075] el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680] do_el0_svc+0x24/0x38 [ 38.237113] el0_svc+0x38/0x168 [ 38.237507] el0t_64_sync_handler+0xa0/0xe8 [ 38.238034] el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end trace 0000000000000000 ]--- There were discussions in [1] at the end of 2023 that mmap() on imported ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46232", "url": "https://ubuntu.com/security/CVE-2026-46232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Clamp num_touch_reports A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43490", "url": "https://ubuntu.com/security/CVE-2026-43490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate inherited ACE SID length smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.num_subauth is fully contained in the ACE. A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. compare_sids() may then read past the ACE. smb_set_ace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and nt_size accounting past the allocated buffer. Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smb_acl.size or the security descriptor allocation size.", "cve_priority": "high", "cve_public_date": "2026-05-15 06:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46110", "url": "https://ubuntu.com/security/CVE-2026-46110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag (\"OWN\") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both \"submissions\" and \"completions.\" In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46007", "url": "https://ubuntu.com/security/CVE-2026-46007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Avoid cacheline sharing for DMA buffer Depending on the architecture the transfer buffer may share a cacheline with the following mutex. As the buffer may be used for DMA, that is problematic. Use the high-level DMA helpers to make sure that cacheline sharing can not happen. Also drop the comment, as the helpers are documentation enough. https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46194", "url": "https://ubuntu.com/security/CVE-2026-46194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix node_cnt race between extent node destroy and writeback f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing extent nodes. When called from f2fs_drop_inode() with I_SYNC set, concurrent kworker writeback can insert new extent nodes into the same extent tree, racing with the destroy and triggering f2fs_bug_on() in __destroy_extent_node(). The scenario is as follows: drop inode writeback - iput - f2fs_drop_inode // I_SYNC set - f2fs_destroy_extent_node - __destroy_extent_node - while (node_cnt) { write_lock(&et->lock) __free_extent_tree write_unlock(&et->lock) - __writeback_single_inode - f2fs_outplace_write_data - f2fs_update_read_extent_cache - __update_extent_tree_range // FI_NO_EXTENT not set, // insert new extent node } // node_cnt == 0, exit while - f2fs_bug_on(node_cnt) // node_cnt > 0 Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected. This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(), consistent with other callers (__update_extent_tree_range and __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and EX_BLOCK_AGE tree.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46114", "url": "https://ubuntu.com/security/CVE-2026-46114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt); check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path. Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46176", "url": "https://ubuntu.com/security/CVE-2026-46176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTR s1 to devr->s0 and devr->s1. This leads to several problems: the lock-free fast path checks \"if (devr->s1) return 0;\" and treats the ERR_PTR as already initialised; users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR and double-frees s0 on teardown. Fix by adding the same `goto unlock` in the s1 failure path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46145", "url": "https://ubuntu.com/security/CVE-2026-46145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46126", "url": "https://ubuntu.com/security/CVE-2026-46126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound. First there is a double i-- on the first failure path due to the while loop having a i--, remove it. Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not undone due to the above i--.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46144", "url": "https://ubuntu.com/security/CVE-2026-46144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46121", "url": "https://ubuntu.com/security/CVE-2026-46121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock Patch series \"mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path\". Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those. This patch (of 2): damon_sysfs_scheme_filter->mmecg_path can be read and written by users, via DAMON sysfs memcg_path file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcg_path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46131", "url": "https://ubuntu.com/security/CVE-2026-46131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: check for nEPT/nNPT in slow flush hypercalls Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46139", "url": "https://ubuntu.com/security/CVE-2026-46139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d (\"smb: common: change the data type of num_aces to le16\") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with \"ndr_pull_security_descriptor failed: Range Error\", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46106", "url": "https://ubuntu.com/security/CVE-2026-46106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Hold eventfs_mutex and SRCU when remount walks events Commit 340f0c7067a9 (\"eventfs: Update all the eventfs_inodes from the events descriptor\") had eventfs_set_attrs() recurse through ei->children on remount. The walk only holds the rcu_read_lock() taken by tracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex. Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo \"p:kp submit_bio\" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done Wrap the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() that take eventfs_mutex and srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract. Comment in tracefs_drop_inode() said \"RCU cycle\" -- it is SRCU.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46129", "url": "https://ubuntu.com/security/CVE-2026-46129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info() error path When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46143", "url": "https://ubuntu.com/security/CVE-2026-46143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46293", "url": "https://ubuntu.com/security/CVE-2026-46293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: microchip: mpfs-ccc: fix out of bounds access during output registration UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43495", "url": "https://ubuntu.com/security/CVE-2026-43495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as a loop bound over port_msg->data[] without checking that the message buffer contains sufficient data. A modem sending port_count=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes. Add a sizeof(*port_msg) check before accessing the port message header fields to guard against undersized messages. Add a struct_size() check after extracting port_count and before the loop. In t7xx_parse_host_rt_data(), guard the rt_feature header read with a remaining-buffer check before accessing data_len, validate feat_data_len against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset. Pass msg_len from both call sites: skb->len at the DPMAIF path after skb_pull(), and the validated feat_data_len at the handshake path.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46142", "url": "https://ubuntu.com/security/CVE-2026-46142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix VF illegal register access Register WX_CFG_PORT_ST is a PF restricted register. When a VF is initialized, attempting to read this register triggers an illegal register access, which lead to a system hang. When the device is VF, the bus function ID can be obtained directly from the PCI_FUNC(pdev->devfn).", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46190", "url": "https://ubuntu.com/security/CVE-2026-46190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show() Sashiko noticed an out-of-bounds read [1]. In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names). Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers \t(element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended. Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count. Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46296", "url": "https://ubuntu.com/security/CVE-2026-46296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: s3c64xx: fix NULL-deref on driver unbind A change moving DMA channel allocation from probe() back to s3c64xx_spi_prepare_transfer() failed to remove the corresponding deallocation from remove(). Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46138", "url": "https://ubuntu.com/security/CVE-2026-46138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access. When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held. Fix this by terminating the BIG if in case not all BIS could be setup properly.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46157", "url": "https://ubuntu.com/security/CVE-2026-46157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46125", "url": "https://ubuntu.com/security/CVE-2026-46125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any \"new_sta\" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46152", "url": "https://ubuntu.com/security/CVE-2026-46152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46136", "url": "https://ubuntu.com/security/CVE-2026-46136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix a potential clc buffer length underflow The buf_len is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC. This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46173", "url": "https://ubuntu.com/security/CVE-2026-46173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying \"WARNING: must be called with preemption disabled!\". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect \"recursively oopsing\" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31499", "url": "https://ubuntu.com/security/CVE-2026-31499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del() l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock. Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-46287", "url": "https://ubuntu.com/security/CVE-2026-46287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix RTNL assertion warning when remove module For the copper NIC with external PHY, the driver called phylink_connect_phy() during probe and phylink_disconnect_phy() during remove. It caused an RTNL assertion warning in phylink_disconnect_phy() upon module remove. To fix this, add rtnl_lock() and rtnl_unlock() around the phylink_disconnect_phy() in remove function. ------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: txgbe_remove_phy+0xbb/0xd0 [txgbe] txgbe_remove+0x4c/0xb0 [txgbe] pci_device_remove+0x41/0xb0 device_remove+0x43/0x80 device_release_driver_internal+0x206/0x270 driver_detach+0x4a/0xa0 bus_remove_driver+0x83/0x120 driver_unregister+0x2f/0x60 pci_unregister_driver+0x40/0x90 txgbe_driver_exit+0x10/0x850 [txgbe] __do_sys_delete_module.isra.0+0x1c3/0x2f0 __x64_sys_delete_module+0x12/0x20 x64_sys_call+0x20c3/0x2390 do_syscall_64+0x11c/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x15a/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_fault+0x312/0x580 ? srso_alias_return_thunk+0x5/0xfbef5 ? __handle_mm_fault+0x9d5/0x1040 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events+0x101/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1e8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x2f8/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? irqentry_exit+0xb2/0x600 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46306", "url": "https://ubuntu.com/security/CVE-2026-46306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: flow_dissector: do not dissect PPPoE PFC frames RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the flow dissector driver has assumed an uncompressed frame until the blamed commit. During the review process of that commit [1], support for PFC is suggested. However, having a compressed (1-byte) protocol field means the subsequent PPP payload is shifted by one byte, causing 4-byte misalignment for the network header and an unaligned access exception on some architectures. The exception can be reproduced by sending a PPPoE PFC frame to an ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE session is active on that interface: $ 0 : 00000000 80c40000 00000000 85144817 $ 4 : 00000008 00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c 0000003d 00000000 $12 : 000000e0 00000039 00000000 00000000 $16 : 85043240 80a75758 81dc9bb8 00006488 $20 : 0000002f 00000007 85144810 80a70000 $24 : 81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000 805ead08 Hi : 00009d51 Lo : 2163358a epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra : 805ead08 __skb_get_hash_net+0x74/0x12c Status: 11000403 KERNEL EXL IE Cause : 40800010 (ExcCode 04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc) Call Trace: [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50 [<805ead08>] __skb_get_hash_net+0x74/0x12c [<805ef330>] get_rps_cpu+0x1b8/0x3fc [<805fca70>] netif_receive_skb_list_internal+0x324/0x364 [<805fd120>] napi_complete_done+0x68/0x2a4 [<8058de5c>] mtk_napi_rx+0x228/0xfec [<805fd398>] __napi_poll+0x3c/0x1c4 [<805fd754>] napi_threaded_poll_loop+0x234/0x29c [<805fd848>] napi_threaded_poll+0x8c/0xb0 [<80053544>] kthread+0x104/0x12c [<80002bd8>] ret_from_kernel_thread+0x14/0x1c Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000 To reduce the attack surface and maintain performance, do not process PPPoE PFC frames. [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46063", "url": "https://ubuntu.com/security/CVE-2026-46063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/shstk: Prevent deadlock during shstk sigreturn During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43109", "url": "https://ubuntu.com/security/CVE-2026-43109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86: shadow stacks: proper error handling for mmap lock 김영민 reports that shstk_pop_sigframe() doesn't check for errors from mmap_read_lock_killable(), which is a silly oversight, and also shows that we haven't marked those functions with \"__must_check\", which would have immediately caught it. So let's fix both issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-46179", "url": "https://ubuntu.com/security/CVE-2026-46179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Don't allow pointer operations on unconfigured streams When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46276", "url": "https://ubuntu.com/security/CVE-2026-46276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix zero-size GDS range init on RDNA4 RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d)", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46083", "url": "https://ubuntu.com/security/CVE-2026-46083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fix resource leaks on device setup failure Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-46282", "url": "https://ubuntu.com/security/CVE-2026-46282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: frequency: admv1013: fix NULL pointer dereference on str When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46084", "url": "https://ubuntu.com/security/CVE-2026-46084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: Disable RX steering on RSS QP destroy When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss() destroys the RX WQ objects but does not disable vPort RX steering in firmware. This leaves stale steering configuration that still points to the destroyed RX objects. If traffic continues to arrive (e.g. peer VM is still transmitting) and the VF interface is subsequently brought up (mana_open), the firmware may deliver completions using stale CQ IDs from the old RX objects. These CQ IDs can be reused by the ethernet driver for new TX CQs, causing RX completions to land on TX CQs: WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false) WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails) Fix this by disabling vPort RX steering before destroying RX WQ objects. Note that mana_fence_rqs() cannot be used here because the fence completion is delivered on the CQ, which is polled by user-mode (e.g. DPDK) and not visible to the kernel driver. Refactor the disable logic into a shared mana_disable_vport_rx() in mana_en, exported for use by mana_ib, replacing the duplicate code. The ethernet driver's mana_dealloc_queues() is also updated to call this common function.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46280", "url": "https://ubuntu.com/security/CVE-2026-46280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: test_hmm: evict device pages on file close to avoid use-after-free Patch series \"Minor hmm_test fixes and cleanups\". Two bugfixes a cleanup for the HMM kernel selftests. These were mostly reported by Zenghui Yu with special thanks to Lorenzo for analysing and pointing out the problems. This patch (of 3): When dmirror_fops_release() is called it frees the dmirror struct but doesn't migrate device private pages back to system memory first. This leaves those pages with a dangling zone_device_data pointer to the freed dmirror. If a subsequent fault occurs on those pages (eg. during coredump) the dmirror_devmem_fault() callback dereferences the stale pointer causing a kernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64, where a test failure triggered SIGABRT and the resulting coredump walked the VMAs faulting in the stale device private pages. Fix this by calling dmirror_device_evict_chunk() for each devmem chunk in dmirror_fops_release() to migrate all device private pages back to system memory before freeing the dmirror struct. The function is moved earlier in the file to avoid a forward declaration.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-45997", "url": "https://ubuntu.com/security/CVE-2026-45997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46075", "url": "https://ubuntu.com/security/CVE-2026-46075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46094", "url": "https://ubuntu.com/security/CVE-2026-46094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46076", "url": "https://ubuntu.com/security/CVE-2026-46076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining \"single\" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46005", "url": "https://ubuntu.com/security/CVE-2026-46005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix a resource leak in xfs_alloc_buftarg() In the error path, call fs_put_dax() to drop the DAX device reference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46031", "url": "https://ubuntu.com/security/CVE-2026-46031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Reinstate disabling of BHs around IRQ handler If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 (\"net: ks8851: Fix deadlock with the SPI chip variant\") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46012", "url": "https://ubuntu.com/security/CVE-2026-46012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix memory leaks in rxkad_verify_response() Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46079", "url": "https://ubuntu.com/security/CVE-2026-46079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: fix null-ptr-deref when device_add_disk() fails do_rbd_add() publishes the device with device_add() before calling device_add_disk(). If device_add_disk() fails after device_add() succeeds, the error path calls rbd_free_disk() directly and then later falls through to rbd_dev_device_release(), which calls rbd_free_disk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set(). Fix this by following the normal remove ordering: call device_del() before rbd_dev_device_release() when device_add_disk() fails after device_add(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong 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. We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer confines failslab injections to the __add_disk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/add_single_major. On the unpatched kernel, fail-nth=4 reliably triggered the fault: \tOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI \tKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \tCPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tRIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 \tCode: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 \tRSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 \tRAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 \tRDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 \tRBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b \tR10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 \tR13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 \tFS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 \tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 \tCR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 \tPKRU: 55555554 \tCall Trace: \t \t blk_mq_free_tag_set+0x77/0x460 \t do_rbd_add+0x1446/0x2b80 \t ? __pfx_do_rbd_add+0x10/0x10 \t ? lock_acquire+0x18c/0x300 \t ? find_held_lock+0x2b/0x80 \t ? sysfs_file_kobj+0xb6/0x1b0 \t ? __pfx_sysfs_kf_write+0x10/0x10 \t kernfs_fop_write_iter+0x2f4/0x4a0 \t vfs_write+0x98e/0x1000 \t ? expand_files+0x51f/0x850 \t ? __pfx_vfs_write+0x10/0x10 \t ksys_write+0xf2/0x1d0 \t ? __pfx_ksys_write+0x10/0x10 \t do_syscall_64+0x115/0x690 \t entry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7f0fbea15907 \tCode: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 \tRSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 \tRAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 \tRDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 \tRBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 \tR10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 \tR13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 \t With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports. [ idryomov: rename err_out_device_del -> err_out_device ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46016", "url": "https://ubuntu.com/security/CVE-2026-46016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: xlnx: Only access buffer information if IPI is buffered In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46061", "url": "https://ubuntu.com/security/CVE-2026-46061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix deadlock in jbd2_journal_cancel_revoke() Commit f76d4c28a46a (\"fs/jbd2: use sleeping version of __find_get_block()\") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A This can occasionally cause generic/013 to hang. Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46011", "url": "https://ubuntu.com/security/CVE-2026-46011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: fix use-after-free in release path due to uncancelled work The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46058", "url": "https://ubuntu.com/security/CVE-2026-46058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amphion: Fix race between m2m job_abort and device_run Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46073", "url": "https://ubuntu.com/security/CVE-2026-46073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when interrupted. This needs to abort the URB and return an error. No data has been received from the device so any reads from the transfer buffer are invalid. The original code tests !ret, which only catches the timeout case (0). On signal delivery (-ERESTARTSYS), !ret is false so the function skips usb_kill_urb() and falls through to read from the unfilled transfer buffer. Fix by capturing the return value into a long (matching the function return type) and handling signal (negative) and timeout (zero) cases with separate checks that both call usb_kill_urb() before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45989", "url": "https://ubuntu.com/security/CVE-2026-45989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: unittest: fix use-after-free in testdrv_probe() The function testdrv_probe() retrieves the device_node from the PCI device, applies an overlay, and then immediately calls of_node_put(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to of_platform_default_populate(), leading to a use-after-free. The reference to pdev->dev.of_node is owned by the device model and should not be released by the driver. Remove the erroneous of_node_put() to prevent premature freeing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45996", "url": "https://ubuntu.com/security/CVE-2026-45996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix use-after-free on unbind The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed). Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46089", "url": "https://ubuntu.com/security/CVE-2026-46089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: do not forget to endio for partial discard requests As reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 takes literally forever to complete. zram doesn't support partial discards and just returns immediately w/o doing any discard work in such cases. The problem is that we forget to endio on our way out, so blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to end_bio label, which does bio_endio().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23468", "url": "https://ubuntu.com/security/CVE-2026-23468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46041", "url": "https://ubuntu.com/security/CVE-2026-46041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger \"BUG: scheduling while atomic\". Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow: 1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46286", "url": "https://ubuntu.com/security/CVE-2026-46286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: qcom-lpg: Check for array overflow when selecting the high resolution When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45993", "url": "https://ubuntu.com/security/CVE-2026-45993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add spectre boundry for syscall dispatch table The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31706", "url": "https://ubuntu.com/security/CVE-2026-31706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory's DACL xattr and uses it to size a heap allocation: aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...); num_aces is a u16 read from le16_to_cpu(parent_pdacl->num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory's security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data. This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels. Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum. Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()'s hash check still passes. A subsequent SMB2 CREATE of a child under that parent drives smb2_open() into smb_inherit_dacl() (share has \"vfs objects = acl_xattr\" set), which fails the page allocator: WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0 Workqueue: ksmbd-io handle_ksmbd_work __alloc_frozen_pages_noprof+0x46c/0x9c0 ___kmalloc_large_node+0x68/0x130 __kmalloc_large_node_noprof+0x24/0x70 __kmalloc_noprof+0x4c9/0x690 smb_inherit_dacl+0x394/0x2430 smb2_open+0x595d/0xabe0 handle_ksmbd_work+0x3d3/0x1140 With the patch applied the added guard rejects the tampered value with -EINVAL before any large allocation runs, smb2_open() falls back to smb2_create_sd_buffer(), and the child is created with a default SD. No warning, no splat. Fix by: 1. Validating num_aces against pdacl_size using the same formula applied in parse_dacl(). 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe allocation. 3. Tightening the per-ACE loop guard to require the minimum valid ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and rejecting under-sized ACEs, matching the hardening in smb_check_perm_dacl() and parse_dacl(). v1 -> v2: - Replace the synthetic test-module splat in the changelog with a real-path UML + KASAN reproduction driven through mount.cifs and SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name in v1 since it does not exist in ksmbd. - Drop the commit-hash citation from the code comment per Namjae's review; keep the parse_dacl() pointer.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31575", "url": "https://ubuntu.com/security/CVE-2026-31575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix hugetlb fault mutex hash calculation In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31582", "url": "https://ubuntu.com/security/CVE-2026-31582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Fix use-after-free on USB disconnect After powerz_disconnect() frees the URB and releases the mutex, a subsequent powerz_read() call can acquire the mutex and call powerz_read_data(), which dereferences the freed URB pointer. Fix by: - Setting priv->urb to NULL in powerz_disconnect() so that powerz_read_data() can detect the disconnected state. - Adding a !priv->urb check at the start of powerz_read_data() to return -ENODEV on a disconnected device. - Moving usb_set_intfdata() before hwmon registration so the disconnect handler can always find the priv pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43073", "url": "https://ubuntu.com/security/CVE-2026-43073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86-64: rename misleadingly named '__copy_user_nocache()' function This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal \"start user space access\" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-21709", "url": "https://ubuntu.com/security/CVE-2025-21709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel: be more careful about dup_mmap() failures and uprobe registering If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f (\"fork: avoid inappropriate uprobe access to invalid mm\") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-31606", "url": "https://ubuntu.com/security/CVE-2026-31606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: don't call cdev_init while cdev in use When calling unbind, then bind again, cdev_init reinitialized the cdev, even though there may still be references to it. That's the case when the /dev/hidg* device is still opened. This obviously unsafe behavior like oopes. This fixes this by using cdev_alloc to put the cdev on the heap. That way, we can simply allocate a new one in hidg_bind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31731", "url": "https://ubuntu.com/security/CVE-2026-31731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Address thermal zone removal races with resume Since thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize the poll_queue delayed work for the given thermal zone, the cancel_delayed_work_sync() in thermal_zone_device_unregister() may miss some already running work items and the thermal zone may be freed prematurely [1]. There are two failing scenarios that both start with running thermal_pm_notify_complete() right before invoking thermal_zone_device_unregister() for one of the thermal zones. In the first scenario, there is a work item already running for the given thermal zone when thermal_pm_notify_complete() calls thermal_zone_pm_complete() for that thermal zone and it continues to run when thermal_zone_device_unregister() starts. Since the poll_queue delayed work has been re-initialized by thermal_pm_notify_complete(), the running work item will be missed by the cancel_delayed_work_sync() in thermal_zone_device_unregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur. In the second scenario, thermal_zone_device_resume() queued up by thermal_pm_notify_complete() runs right after the thermal_zone_exit() called by thermal_zone_device_unregister() has returned. The poll_queue delayed work is re-initialized by it before cancel_delayed_work_sync() is called by thermal_zone_device_unregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free. Address the first failing scenario by ensuring that no thermal work items will be running when thermal_pm_notify_complete() is called. For this purpose, first move the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended). The second failing scenario is addressed by adding a tz->state check to thermal_zone_device_resume() to prevent it from re-initializing the poll_queue delayed work if the thermal zone is going away. Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31677", "url": "https://ubuntu.com/security/CVE-2026-31677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43107", "url": "https://ubuntu.com/security/CVE-2026-43107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: account XFRMA_IF_ID in aevent size calculation xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set. xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic. Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43119", "url": "https://ubuntu.com/security/CVE-2026-43119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering).", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31702", "url": "https://ubuntu.com/security/CVE-2026-31702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io() In f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bring the F2FS_WB_CP_DATA counter to zero, unblocking f2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmount CPU. The unmount path then proceeds to call f2fs_destroy_page_array_cache(sbi), which destroys sbi->page_array_slab via kmem_cache_destroy(), and eventually kfree(sbi). Meanwhile, the bio completion callback is still executing: when it reaches page_array_free(sbi, ...), it dereferences sbi->page_array_slab — a destroyed slab cache — to call kmem_cache_free(), causing a use-after-free. This is the same class of bug as CVE-2026-23234 (which fixed the equivalent race in f2fs_write_end_io() in data.c), but in the compressed writeback completion path that was not covered by that fix. Fix this by moving dec_page_count() to after page_array_free(), so that all sbi accesses complete before the counter decrement that can unblock unmount. For non-last folios (where atomic_dec_return on cic->pending_pages is nonzero), dec_page_count is called immediately before returning — page_array_free is not reached on this path, so there is no post-decrement sbi access. For the last folio, page_array_free runs while the F2FS_WB_CP_DATA counter is still nonzero (this folio has not yet decremented it), keeping sbi alive, and dec_page_count runs as the final operation.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31704", "url": "https://ubuntu.com/security/CVE-2026-31704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use check_add_overflow() to prevent u16 DACL size overflow set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char *)pndace + *size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value. Use check_add_overflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing check_mul_overflow() usage elsewhere in smbacl.c.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31714", "url": "https://ubuntu.com/security/CVE-2026-31714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid memory leak in f2fs_rename() syzbot reported a f2fs bug as below: BUG: memory leak unreferenced object 0xffff888127f70830 (size 16): comm \"syz.0.23\", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in commit 40b2d55e0452 (\"f2fs: fix to create selinux label during whiteout initialization\"), we added a call to f2fs_setup_filename() without a matching call to f2fs_free_filename(), fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31595", "url": "https://ubuntu.com/security/CVE-2026-31595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31584", "url": "https://ubuntu.com/security/CVE-2026-31584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: fix use-after-free in encoder release path The fops_vcodec_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encode_work. This creates a race window where the workqueue handler (mtk_venc_worker) may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job \"done\" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job \"done\" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job \"done\") kfree(ctx) // ctx freed Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. After v4l2_m2m_job_finish() is called, the m2m framework considers the job complete and v4l2_m2m_ctx_release() returns, but the worker function continues executing and may still access ctx. The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx fields even after calling v4l2_m2m_job_finish(). This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed. Placement rationale: The fix is placed after v4l2_ctrl_handler_free() and before list_del_init(&ctx->list). At this point, all m2m operations are done (v4l2_m2m_ctx_release() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during device_run() operations.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31587", "url": "https://ubuntu.com/security/CVE-2026-31587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm: move component registration to unmanaged version q6apm component registers dais dynamically from ASoC toplology, which are allocated using device managed version apis. Allocating both component and dynamic dais using managed version could lead to incorrect free ordering, dai will be freed while component still holding references to it. Fix this issue by moving component to unmanged version so that the dai pointers are only freeded after the component is removed. ================================================================== BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426 Tainted: [W]=WARN Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024 Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] Call trace: show_stack+0x28/0x7c (C) dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Allocated by task 77: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194 __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Freed by task 3426: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31604", "url": "https://ubuntu.com/security/CVE-2026-31604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix device leak on probe failure Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on all probe errors (e.g. when descriptor parsing fails). Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31611", "url": "https://ubuntu.com/security/CVE-2026-31611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require 3 sub-authorities before reading sub_auth[2] parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares only min(num_subauth, 2) sub-authorities so a client SID with num_subauth = 2 and sub_auth = {88, 3} will match. If num_subauth = 2 and the ACE is placed at the very end of the security descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen. Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31612", "url": "https://ubuntu.com/security/CVE-2026-31612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate EaNameLength in smb2_get_ea() smb2_get_ea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received. Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a \"trusted\" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43072", "url": "https://ubuntu.com/security/CVE-2026-43072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: platform_get_irq_byname() returns an int platform_get_irq_byname() will return a negative value if an error happens, so it should be checked and not just passed directly into devm_request_threaded_irq() hoping all will be ok.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43345", "url": "https://ubuntu.com/security/CVE-2026-43345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix event ring index not programmed for IPA v5.0+ For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to CH_C_CNTXT_1. The v5.0 register definition intended to define this field in the CH_C_CNTXT_1 fmask array but used the old identifier of ERINDEX instead of CH_ERINDEX. Without a valid event ring, GSI channels could never signal transfer completions. This caused gsi_channel_trans_quiesce() to block forever in wait_for_completion(). At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43081", "url": "https://ubuntu.com/security/CVE-2026-43081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+ Fix the field masks to match the hardware layout documented in downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*). Notably this fixes a WARN I was seeing when I tried to send \"stop\" to the MPSS remoteproc while IPA was up.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43082", "url": "https://ubuntu.com/security/CVE-2026-43082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: leave space for null terminators on property_entry Lists of struct property_entry are supposed to be terminated with an empty property, this driver currently seems to be allocating exactly the amount of entry used. Change the struct definition to leave an extra element for all property_entry.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43086", "url": "https://ubuntu.com/security/CVE-2026-43086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix NULL deref in ip_vs_add_service error path When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local variable sched is set to NULL. If ip_vs_start_estimator() subsequently fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched) with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL check (because svc->scheduler was set by the successful bind) but then dereferences the NULL sched parameter at sched->done_service, causing a kernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..] Fix by simply not clearing the local sched variable after a successful bind. ip_vs_unbind_scheduler() already detects whether a scheduler is installed via svc->scheduler, and keeping sched non-NULL ensures the error path passes the correct pointer to both ip_vs_unbind_scheduler() and ip_vs_scheduler_put(). While the bug is older, the problem popups in more recent kernels (6.2), when the new error path is taken after the ip_vs_start_estimator() call.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43091", "url": "https://ubuntu.com/security/CVE-2026-43091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Wait for RCU readers during policy netns exit xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43092", "url": "https://ubuntu.com/security/CVE-2026-43092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate MTU against usable frame size on bind AF_XDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk. This becomes a problem since we started to respect tailroom which is subtracted from chunk_size (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via net_device::xdp_zc_max_segs).", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43094", "url": "https://ubuntu.com/security/CVE-2026-43094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: add missing negotiate_features op to Hyper-V ops table Commit a7075f501bd3 (\"ixgbevf: fix mailbox API compatibility by negotiating supported features\") added the .negotiate_features callback to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL on Hyper-V VMs. During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(), which unconditionally dereferences hw->mac.ops.negotiate_features(). On Hyper-V this results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events work_for_cpu_fn RIP: 0010:0x0 [...] Call Trace: ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...] Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP gracefully.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43120", "url": "https://ubuntu.com/security/CVE-2026-43120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix double free related to rereg_user_mr If IB_MR_REREG_TRANS is set during rereg_user_mr, the umem will be released and a new one will be allocated in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans fails after the new umem is allocated, it releases the umem, but does not set iwmr->region to NULL. The problem is that this failure is propagated to the user, who will then call ibv_dereg_mr (as they should). Then, the dereg_mr path will see a non-NULL umem and attempt to call ib_umem_release again. Fix this by setting iwmr->region to NULL after ib_umem_release. Fixed: 5ac388db27c4 (\"RDMA/irdma: Add support to re-register a memory region\")", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31429", "url": "https://ubuntu.com/security/CVE-2026-31429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skb: fix cross-cache free of KFENCE-allocated skb head SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2 value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc bucket sizes. This ensures that skb_kfree_head() can reliably use skb_end_offset to distinguish skb heads allocated from skb_small_head_cache vs. generic kmalloc caches. However, when KFENCE is enabled, kfence_ksize() returns the exact requested allocation size instead of the slab bucket size. If a caller (e.g. bpf_test_init) allocates skb head data via kzalloc() and the requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then slab_build_skb() -> ksize() returns that exact value. After subtracting skb_shared_info overhead, skb_end_offset ends up matching SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free the object to skb_small_head_cache instead of back to the original kmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1k Fix this by always calling kfree(head) in skb_kfree_head(). This keeps the free path generic and avoids allocator-specific misclassification for KFENCE objects.", "cve_priority": "medium", "cve_public_date": "2026-04-20 10:16:00 UTC" }, { "cve": "CVE-2026-31645", "url": "https://ubuntu.com/security/CVE-2026-31645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page pool leak in error paths lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error paths.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23302", "url": "https://ubuntu.com/security/CVE-2026-23302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: annotate data-races around sk->sk_{data_ready,write_space} skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently. Add corresponding READ_ONCE()/WRITE_ONCE() annotations for UDP, TCP and AF_UNIX.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23330", "url": "https://ubuntu.com/security/CVE-2026-23330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: complete pending data exchange on device close In nci_close_device(), complete any pending data exchange before closing. The data exchange callback (e.g. rawsock_data_exchange_complete) holds a socket reference. NIPA occasionally hits this leak: unreferenced object 0xff1100000f435000 (size 2048): comm \"nci_dev\", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23374", "url": "https://ubuntu.com/security/CVE-2026-23374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blktrace: fix __this_cpu_read/write in preemptible context tracing_record_cmdline() internally uses __this_cpu_read() and __this_cpu_write() on the per-CPU variable trace_cmdline_save, and trace_save_cmdline() explicitly asserts preemption is disabled via lockdep_assert_preemption_disabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probe_wakeup_sched_switch() / probe_wakeup()). __blk_add_trace() was calling tracing_record_cmdline(current) early in the blk_tracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002: blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message) [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 [ 81.362895] check_preemption_disabled+0xce/0xe0 [ 81.362902] tracing_record_cmdline+0x10/0x40 [ 81.362923] __blk_add_trace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30 [ 81.362959] blk_add_trace_bio+0x106/0x1e0 [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0 [ 81.362979] ? lockdep_init_map_type+0x58/0x260 [ 81.362988] submit_bio_wait+0x56/0x90 [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250 [ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10 [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0 [ 81.363051] blkdev_read_iter+0xc1/0x140 [ 81.363059] vfs_read+0x20b/0x330 [ 81.363083] ksys_read+0x67/0xe0 [ 81.363090] do_syscall_64+0xbf/0xf00 [ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(), and blk_add_trace_rq() paths as well. The purpose of tracin ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31638", "url": "https://ubuntu.com/security/CVE-2026-31638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Only put the call ref if one was acquired rxrpc_input_packet_on_conn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is no reference to drop. The client-side implicit-end error path does not account for that and unconditionally calls rxrpc_put_call(). This turns a protocol error path into a kernel crash instead of rejecting the packet. Only drop the call reference if one was actually acquired. Keep the existing protocol error handling unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31639", "url": "https://ubuntu.com/security/CVE-2026-31639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference count leak from call->key When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ After the patch, the invalidated key is removed when the code exits: $ cat /proc/keys | grep afs@54321 $", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31646", "url": "https://ubuntu.com/security/CVE-2026-31646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31648", "url": "https://ubuntu.com/security/CVE-2026-31648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: filemap: fix nr_pages calculation overflow in filemap_map_pages() When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as \"Bad page state\": \" [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount \" After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can reproduce the crash as well and captured the first warning where the issue appears: \" [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):\"stress-ng-mmaptorture-9397-0-2736200540\" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P) [ 734.469555] set_pte_range+0xd8/0x2f8 [ 734.469566] filemap_map_folio_range+0x190/0x400 [ 734.469579] filemap_map_pages+0x348/0x638 [ 734.469583] do_fault_around+0x140/0x198 ...... [ 734.469640] el0t_64_sync+0x184/0x188 \" The code that triggers the warning is: \"VM_WARN_ON_FOLIO(page_folio(page + nr_pages - 1) != folio, folio)\", which indicates that set_pte_range() tried to map beyond the large folio’s size. By adding more debug information, I found that 'nr_pages' had overflowed in filemap_map_pages(), causing set_pte_range() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->_mapcount). After above analysis, I think the possible race is as follows: CPU 0 CPU 1 filemap_map_pages() ext4_setattr() //get and lock folio with old inode->i_size next_uptodate_folio() ....... //shrink the inode->i_size i_size_write(inode, attr->ia_size); //calculate the end_pgoff with the new inode->i_size file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; end_pgoff = min(end_pgoff, file_end); ...... //nr_pages can be overflowed, cause xas.xa_index > end_pgoff end = folio_next_index(folio) - 1; nr_pages = min(end, end_pgoff) - xas.xa_index + 1; ...... //map large folio filemap_map_folio_range() ...... //truncate folios truncate_pagecache(inode, inode->i_size); To fix this issue, move the 'end_pgoff' calculation before next_uptodate_folio(), so the retrieved folio stays consistent with the file end to avoid ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31655", "url": "https://ubuntu.com/security/CVE-2026-31655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31689", "url": "https://ubuntu.com/security/CVE-2026-31689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/mc: Fix error path ordering in edac_mc_alloc() When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch.", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31430", "url": "https://ubuntu.com/security/CVE-2026-31430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: X.509: Fix out-of-bounds access when parsing extensions Leo reports an out-of-bounds access when parsing a certificate with empty Basic Constraints or Key Usage extension because the first byte of the extension is read before checking its length. Fix it. The bug can be triggered by an unprivileged user by submitting a specially crafted certificate to the kernel through the keyrings(7) API. Leo has demonstrated this with a proof-of-concept program responsibly disclosed off-list.", "cve_priority": "medium", "cve_public_date": "2026-04-20 10:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2025-62626", "url": "https://ubuntu.com/security/CVE-2025-62626", "cve_description": "Improper handling of insufficient entropy in the AMD CPUs could allow a local attacker to influence the values returned by the RDSEED instruction, potentially resulting in the consumption of insufficiently random values.", "cve_priority": "medium", "cve_public_date": "2025-11-21 19:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43056", "url": "https://ubuntu.com/security/CVE-2026-43056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in add_adev() error path If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls auxiliary_device_uninit(adev). The auxiliary device has its release callback set to adev_release(), which frees the containing struct mana_adev. Since adev is embedded in struct mana_adev, the subsequent fall-through to init_fail and access to adev->id may result in a use-after-free. Fix this by saving the allocated auxiliary device id in a local variable before calling auxiliary_device_add(), and use that saved id in the cleanup path after auxiliary_device_uninit().", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43057", "url": "https://ubuntu.com/security/CVE-2026-43057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback NETIF_F_IPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO. The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly. A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31722", "url": "https://ubuntu.com/security/CVE-2026-31722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowed_net flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31723", "url": "https://ubuntu.com/security/CVE-2026-31723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31724", "url": "https://ubuntu.com/security/CVE-2026-31724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31725", "url": "https://ubuntu.com/security/CVE-2026-31725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-71269", "url": "https://ubuntu.com/security/CVE-2025-71269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not free data reservation in fallback from inline due to -ENOSPC If we fail to create an inline extent due to -ENOSPC, we will attempt to go through the normal COW path, reserve an extent, create an ordered extent, etc. However we were always freeing the reserved qgroup data, which is wrong since we will use data. Fix this by freeing the reserved qgroup data in __cow_file_range_inline() only if we are not doing the fallback (ret is <= 0).", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23389", "url": "https://ubuntu.com/security/CVE-2026-23389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix memory leak in ice_set_ringparam() In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31729", "url": "https://ubuntu.com/security/CVE-2026-31729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_notify_common() The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries). A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsi_connector_change(). Add a bounds check in ucsi_notify_common(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31730", "url": "https://ubuntu.com/security/CVE-2026-31730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: possible double-free of cctx->remote_heap fastrpc_init_create_static_process() may free cctx->remote_heap on the err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove() frees cctx->remote_heap again if it is non-NULL, which can lead to a double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg device is subsequently removed/unbound. Clear cctx->remote_heap after freeing it in the error path to prevent the later cleanup from freeing it again. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43332", "url": "https://ubuntu.com/security/CVE-2026-43332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone device registration error path If thermal_zone_device_register_with_trips() fails after registering a thermal zone device, it needs to wait for the tz->removal completion like thermal_zone_device_unregister(), in case user space has managed to take a reference to the thermal zone device's kobject, in which case thermal_release() may not be called by the error path itself and tz may be freed prematurely. Add the missing wait_for_completion() call to the thermal zone device registration error path.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31740", "url": "https://ubuntu.com/security/CVE-2026-31740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member The counter driver can use HW channels 1 and 2, while the PWM driver can use HW channels 0, 1, 2, 3, 4, 6, 7. The dev member is assigned both by the counter driver and the PWM driver for channels 1 and 2, to their own struct device instance, overwriting the previous value. The sub-drivers race to assign their own struct device pointer to the same struct rz_mtu3_channel's dev member. The dev member of struct rz_mtu3_channel is used by the counter sub-driver for runtime PM. Depending on the probe order of the counter and PWM sub-drivers, the dev member may point to the wrong struct device instance, causing the counter sub-driver to do runtime PM actions on the wrong device. To fix this, use the parent pointer of the counter, which is assigned during probe to the correct struct device, not the struct device pointer inside the shared struct rz_mtu3_channel.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31741", "url": "https://ubuntu.com/security/CVE-2026-31741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: rz-mtu3-cnt: prevent counter from being toggled multiple times Runtime PM counter is incremented / decremented each time the sysfs enable file is written to. If user writes 0 to the sysfs enable file multiple times, runtime PM usage count underflows, generating the following message. rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow! At the same time, hardware registers end up being accessed with clocks off in rz_mtu3_terminate_counter() to disable an already disabled channel. If user writes 1 to the sysfs enable file multiple times, runtime PM usage count will be incremented each time, requiring the same number of 0 writes to get it back to 0. If user writes 0 to the sysfs enable file while PWM is in progress, PWM is stopped without counter being the owner of the underlying MTU3 channel. Check against the cached count_is_enabled value and exit if the user is trying to set the same enable value.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31767", "url": "https://ubuntu.com/security/CVE-2026-31767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things. This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode. Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads. (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31768", "url": "https://ubuntu.com/security/CVE-2026-31768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ti-adc161s626: use DMA-safe memory for spi_read() Add a DMA-safe buffer and use it for spi_read() instead of a stack memory. All SPI buffers must be DMA-safe. Since we only need up to 3 bytes, we just use a u8[] instead of __be16 and __be32 and change the conversion functions appropriately.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31432", "url": "https://ubuntu.com/security/CVE-2026-31432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix OOB write in QUERY_INFO for compound requests When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor. The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs. This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31772", "url": "https://ubuntu.com/security/CVE-2026-31772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31779", "url": "https://ubuntu.com/security/CVE-2026-31779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler() The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43007", "url": "https://ubuntu.com/security/CVE-2026-43007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Handle DBC deactivation if the owner went away When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles this by calling decode_deactivate() to release the resources allocated for that DBC. Since that handling is done in the qaic_manage_ioctl() context, if the user goes away before receiving and handling the deactivation, the host will be out-of-sync with the DBCs available for use, and the DBC resources will not be freed unless the device is removed. If another user loads and requests to activate a network, then the device assigns the same DBC to that network, QAIC will \"indefinitely\" wait for dbc->in_use = false, leading the user process to hang. As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions that are received after the user has gone away.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43012", "url": "https://ubuntu.com/security/CVE-2026-43012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix switchdev mode rollback in case of failure If for some internal reason switchdev mode fails, we rollback to legacy mode, before this patch, rollback will unregister the uplink netdev and leave it unregistered causing the below kernel bug. To fix this, we need to avoid netdev unregister by setting the proper rollback flag 'MLX5_PRIV_FLAGS_SWITCH_LEGACY' to indicate legacy mode. devlink (431) used greatest stack depth: 11048 bytes left mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \\ \tnecvfs(0), active vports(0) mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535 mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \\ \tQUERY_HCA_CAP(0x100) op_mod(0x0) failed, \\ \tstatus bad parameter(0x3), syndrome (0x3a3846), err(-22) mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \\ \trepresentor for vport 65535 ------------[ cut here ]------------ kernel BUG at net/core/dev.c:12070! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \\ \t#9 PREEMPT(voluntary) RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0 ... Call Trace: [ 90.923094] unregister_netdevice_queue+0xad/0xf0 [ 90.923323] unregister_netdev+0x1c/0x40 [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6 [ 90.923736] esw_offloads_enable+0x8e6/0x920 [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430 [ 90.924182] ? is_mp_supported+0x57/0xb0 [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350 [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0 [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140 [ 90.925088] genl_rcv_msg+0x18b/0x290 [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10 [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10 [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10 [ 90.926206] netlink_rcv_skb+0x52/0x100 [ 90.926393] genl_rcv+0x28/0x40 [ 90.926557] netlink_unicast+0x27d/0x3d0 [ 90.926749] netlink_sendmsg+0x1f7/0x430 [ 90.926942] __sys_sendto+0x213/0x220 [ 90.927127] ? __sys_recvmsg+0x6a/0xd0 [ 90.927312] __x64_sys_sendto+0x24/0x30 [ 90.927504] do_syscall_64+0x50/0x1c0 [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 90.927929] RIP: 0033:0x7f7d0363e047", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43013", "url": "https://ubuntu.com/security/CVE-2026-43013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: lag: Check for LAG device before creating debugfs __mlx5_lag_dev_add_mdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5_ldev_add_debugfs() even when there is no valid LAG context. mlx5_ldev_add_debugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL. Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer before attempting to create the debugfs entries.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31675", "url": "https://ubuntu.com/security/CVE-2026-31675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_netem: fix out-of-bounds access in packet corruption In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0. Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access. Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43016", "url": "https://ubuntu.com/security/CVE-2026-43016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready(). syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0] In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock(). Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after one RCU grace period. Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops under RCU in sk_psock_verdict_data_ready(). [0]: BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013 CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7facf899c819 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 15: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43017", "url": "https://ubuntu.com/security/CVE-2026-43017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate mesh send advertising payload length mesh_send() currently bounds MGMT_OP_MESH_SEND by total command length, but it never verifies that the bytes supplied for the flexible adv_data[] array actually match the embedded adv_data_len field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer. Keep rejecting zero-length and oversized advertising payloads, but validate adv_data_len explicitly and require the command length to exactly match the flexible array size before queueing the request.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43018", "url": "https://ubuntu.com/security/CVE-2026-43018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43019", "url": "https://ubuntu.com/security/CVE-2026-43019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently. Take hdev lock to prevent hci_conn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid \"tearing\" in the configuration.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43023", "url": "https://ubuntu.com/security/CVE-2026-43023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43025", "url": "https://ubuntu.com/security/CVE-2026-43025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ignore explicit helper on new expectations Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation. This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350 Allowing to read kernel memory bytes off the expectation boundary. CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43036", "url": "https://ubuntu.com/security/CVE-2026-43036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: use skb_header_pointer() for TCPv4 GSO frag_off check Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1]. gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths. Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying. [1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43330", "url": "https://ubuntu.com/security/CVE-2026-43330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - fix overflow on long hmac keys When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The copying is performed using kmemdup, however this leads to an overflow: reading more bytes (aligned_len - keylen) from the keylen source buffer. Fix this by replacing kmemdup with kmalloc, followed by memcpy.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43044", "url": "https://ubuntu.com/security/CVE-2026-43044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - fix DMA corruption on long hmac keys When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43338", "url": "https://ubuntu.com/security/CVE-2026-43338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reserve enough transaction items for qgroup ioctls Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve. However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve. For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNT When running this, we can see in dmesg/syslog that a transaction abort happened: [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] [436.530] btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ? __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43049", "url": "https://ubuntu.com/security/CVE-2026-43049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure Presently, if the force feedback initialisation fails when probing the Logitech G920 Driving Force Racing Wheel for Xbox One, an error number will be returned and propagated before the userspace infrastructure (sysfs and /dev/input) has been torn down. If userspace ignores the errors and continues to use its references to these dangling entities, a UAF will promptly follow. We have 2 options; continue to return the error, but ensure that all of the infrastructure is torn down accordingly or continue to treat this condition as a warning by emitting the message but returning success. It is thought that the original author's intention was to emit the warning but keep the device functional, less the force feedback feature, so let's go with that.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43067", "url": "https://ubuntu.com/security/CVE-2026-43067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 (\"ext4: always allocate blocks only from groups inode can use\") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-39930", "url": "https://ubuntu.com/security/CVE-2025-39930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai() commit 419d1918105e (\"ASoC: simple-card-utils: use __free(device_node) for device node\") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use. Don't use __free(device_node) in graph_util_parse_dai().", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2026-46244", "url": "https://ubuntu.com/security/CVE-2026-46244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: Fix IPv6 inner_thoff desync In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2. For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.", "cve_priority": "medium", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-46289", "url": "https://ubuntu.com/security/CVE-2026-46289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/scatterlist: fix length calculations in extract_kvec_to_sg Patch series \"Fix bugs in extract_iter_to_sg()\", v3. Fix bugs in the kvec and user variants of extract_iter_to_sg. This series is growing due to useful remarks made by sashiko.dev. The main bugs are: - The length for an sglist entry when extracting from a kvec can exceed the number of bytes in the page. This is obviously not intended. - When extracting a user buffer the sglist is temporarily used as a scratch buffer for extracted page pointers. If the sglist already contains some elements this scratch buffer could overlap with existing entries in the sglist. The series adds test cases to the kunit_iov_iter test that demonstrate all of these bugs. Additionally, there is a memory leak fix for the test itself. The bugs were orignally introduced into kernel v6.3 where the function lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in v6.5. Thus the actual fix is only marked for backports to v6.5+. This patch (of 5): When extracting from a kvec to a scatterlist, do not cross page boundaries. The required length was already calculated but not used as intended. Adjust the copied length if the loop runs out of sglist entries without extracting everything. While there, return immediately from extract_iter_to_sg if there are no sglist entries at all. A subsequent commit will add kunit test cases that demonstrate that the patch is necessary.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46185", "url": "https://ubuntu.com/security/CVE-2026-46185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46115", "url": "https://ubuntu.com/security/CVE-2026-46115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: add pgmap check to biovec_phys_mergeable biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31436", "url": "https://ubuntu.com/security/CVE-2026-31436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc() At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43384", "url": "https://ubuntu.com/security/CVE-2026-43384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31448", "url": "https://ubuntu.com/security/CVE-2026-31448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid infinite loops caused by residual data On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about \"inserted\" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43378", "url": "https://ubuntu.com/security/CVE-2026-43378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix use-after-free in smb2_open() The opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is dereferenced after rcu_read_unlock(), creating a use-after-free window.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2158930, 2158377, 2137199, 2131077, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155660, 2154496, 2154496, 2154496 ], "changes": [ { "cves": [ { "cve": "CVE-2026-46117", "url": "https://ubuntu.com/security/CVE-2026-46117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46137", "url": "https://ubuntu.com/security/CVE-2026-46137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46314", "url": "https://ubuntu.com/security/CVE-2026-46314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject empty multisync extension to prevent infinite loop v3d_get_extensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL; The guard never fires because v3d_get_multisync_post_deps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely. Fix this by rejecting a multisync extension where both in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46274", "url": "https://ubuntu.com/security/CVE-2026-46274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.", "cve_priority": "high", "cve_public_date": "2026-06-08 16:16:00 UTC" }, { "cve": "CVE-2026-31707", "url": "https://ubuntu.com/security/CVE-2026-31707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate response sizes in ipc_validate_msg() ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t); resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply. A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length. Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX. The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed. This is the response-side analogue of aab98e2dbd64 (\"ksmbd: fix integer overflows on 32 bit systems\"), which hardened the request side.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46068", "url": "https://ubuntu.com/security/CVE-2026-46068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31613", "url": "https://ubuntu.com/security/CVE-2026-31613", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB reads parsing symlink error response When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server. symlink_data() walks SMB 3.1.1 error contexts with the loop test \"p < end\", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits. smb2_parse_symlink_response() then bounds-checks the substitute name using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from iov_base. That value is computed as sizeof(smb2_err_rsp) + sizeof(smb2_symlink_err_rsp), which is correct only when ErrorContextCount == 0. With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iov_len. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2). Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset. Because sub_offs and sub_len are 16bits, the pointer math will not overflow here with the new greater-than.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43245", "url": "https://ubuntu.com/security/CVE-2026-43245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs: ->d_compare() must not block ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-45846", "url": "https://ubuntu.com/security/CVE-2026-45846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst() bareudp_fill_metadata_dst() passes bareudp->sock to udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check. The socket is only created in bareudp_open() and NULLed in bareudp_stop(), so calling this function while the device is down triggers a NULL dereference via sock->sk. BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160) Call Trace: bareudp_fill_metadata_dst (drivers/net/bareudp.c:532) do_execute_actions (net/openvswitch/actions.c:901) ovs_execute_actions (net/openvswitch/actions.c:1589) ovs_packet_cmd_execute (net/openvswitch/datapath.c:700) genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114) genl_rcv_msg (net/netlink/genetlink.c:1209) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths in the same driver.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45845", "url": "https://ubuntu.com/security/CVE-2026-45845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: fix NULL pointer dereference in class dump When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTM_GETTCLASS dump operations walk all classes via taprio_walk() and call taprio_dump_class(), which calls taprio_leaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference. The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTM_GETTCLASS dump itself requires no capability. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478) Call Trace: tc_fill_tclass (net/sched/sch_api.c:1966) qdisc_class_dump (net/sched/sch_api.c:2326) taprio_walk (net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc (net/sched/sch_api.c:2352) tc_dump_tclass_root (net/sched/sch_api.c:2370) tc_dump_tclass (net/sched/sch_api.c:2431) rtnl_dumpit (net/core/rtnetlink.c:6864) netlink_dump (net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg (net/core/rtnetlink.c:6959) netlink_rcv_skb (net/netlink/af_netlink.c:2550) Fix this by substituting &noop_qdisc when new is NULL in taprio_graft(), a common pattern used by other qdiscs (e.g., multiq_graft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks. Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noop_qdisc instead. Without this, packets would reach taprio_enqueue_one() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics. After this change *old can be a valid qdisc, NULL, or &noop_qdisc. Only call qdisc_put(*old) in the first case to avoid decreasing noop_qdisc's refcount, which was never increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45844", "url": "https://ubuntu.com/security/CVE-2026-45844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: arp_tables: fix IEEE1394 ARP payload parsing Weiming Shi says: \"arp_packet_match() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arp_hdr_len() already accounts for this by returning a shorter length for ARPHRD_IEEE1394 devices. As a result, on IEEE1394 interfaces arp_packet_match() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa. The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already handles this correctly by skipping the target hardware address for ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match().\" Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394. Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRD_IEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle to drop the packet too as AI suggests: In arpt_mangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NF_DROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload. This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arpt_mangle offset calculation, which has never been supported. Based on patch from Weiming Shi .", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45843", "url": "https://ubuntu.com/security/CVE-2026-45843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45842", "url": "https://ubuntu.com/security/CVE-2026-45842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: reject VJ receive packets on instances with no rstate array slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp->rstate stays NULL and comp->rslot_limit stays 0 (from the kzalloc of struct slcompress). The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate. The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519) Call Trace: ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466) ppp_input (drivers/net/ppp/ppp_generic.c:2359) ppp_async_process (drivers/net/ppp/ppp_async.c:492) tasklet_action_common (kernel/softirq.c:926) handle_softirqs (kernel/softirq.c:623) run_ksoftirqd (kernel/softirq.c:1055) smpboot_thread_fn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:164) Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet. The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and slip.c always calls slhc_init(16, 16), so comp->tstate remains valid and slhc_compress() continues to work.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45841", "url": "https://ubuntu.com/security/CVE-2026-45841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO nf_osf_match_one() computes ctx->window % f->wss.val in the OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel. Reject the bogus fingerprint in nfnl_osf_add_callback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->opt_num (including 0). Also reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that as \"should not happen\". Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98) Call Trace: nf_osf_match (net/netfilter/nfnetlink_osf.c:220) xt_osf_match_packet (net/netfilter/xt_osf.c:32) ipt_do_table (net/ipv4/netfilter/ip_tables.c:348) nf_hook_slow (net/netfilter/core.c:622) ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv (include/linux/skbuff.h:1162) __netif_receive_skb_one_core (net/core/dev.c:6181) process_backlog (net/core/dev.c:6642) __napi_poll (net/core/dev.c:7710) net_rx_action (net/core/dev.c:7945) handle_softirqs (kernel/softirq.c:622)", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45840", "url": "https://ubuntu.com/security/CVE-2026-45840", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: cap upcall PID array size and pre-size vport replies The vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn since OVS vport mutation operations use GENL_UNS_ADMIN_PERM. kernel BUG at net/openvswitch/datapath.c:2414! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1 RIP: 0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace: genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116) genl_rcv_msg (net/netlink/genetlink.c:1194) netlink_rcv_skb (net/netlink/af_netlink.c:2550) genl_rcv (net/netlink/genetlink.c:1219) netlink_unicast (net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Kernel panic - not syncing: Fatal exception Reject attempts to set more PIDs than nr_cpu_ids in ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply size in ovs_vport_cmd_msg_size() based on that bound, similar to the existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already used by the per-CPU dispatch configuration on the datapath side (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the two sides stay consistent.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46319", "url": "https://ubuntu.com/security/CVE-2026-46319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-45839", "url": "https://ubuntu.com/security/CVE-2026-45839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec() CO-RE accessor strings are colon-separated indices that describe a path from a root BTF type to a target field, e.g. \"0:1:2\" walks through nested struct members. bpf_core_parse_spec() parses each component with sscanf(\"%d\"), so negative values like -1 are silently accepted. The subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the upper bound and always pass for negative values because C integer promotion converts the __u16 btf_vlen result to int, making the comparison (int)(-1) >= (int)(N) false for any positive N. When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff, producing an out-of-bounds read far past the members array. A crafted BPF program with a negative CO-RE accessor on any struct that exists in vmlinux BTF (e.g. task_struct) crashes the kernel deterministically during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y (default on major distributions). The bug is reachable with CAP_BPF: BUG: unable to handle page fault for address: ffffed11818b6626 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full) RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354) RAX: 00000000ffffffff Call Trace: bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321) bpf_core_apply (kernel/bpf/btf.c:9507) check_core_relo (kernel/bpf/verifier.c:19475) bpf_check (kernel/bpf/verifier.c:26031) bpf_prog_load (kernel/bpf/syscall.c:3089) __sys_bpf (kernel/bpf/syscall.c:6228) CO-RE accessor indices are inherently non-negative (struct member index, array element index, or enumerator index), so reject them immediately after parsing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-45838", "url": "https://ubuntu.com/security/CVE-2026-45838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.", "cve_priority": "low", "cve_public_date": "2026-05-27 11:16:00 UTC" }, { "cve": "CVE-2026-46207", "url": "https://ubuntu.com/security/CVE-2026-46207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix empty payload in tap skb for non-linear buffers For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized. Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb(). While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46164", "url": "https://ubuntu.com/security/CVE-2026-46164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info_sub_group() error path When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46201", "url": "https://ubuntu.com/security/CVE-2026-46201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() When xe_dma_buf_init_obj() fails, the attachment from dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before returning the error. Note: we cannot use goto out_err here because xe_dma_buf_init_obj() already frees bo on failure, and out_err would double-free it. (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46211", "url": "https://ubuntu.com/security/CVE-2026-46211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata() msm_ioctl_gem_info_get_metadata() always returns 0 regardless of errors. When copy_to_user() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not. Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copy_to_user() call. Add the missing NULL check for kmemdup() and return ret instead of 0. Note that the SET counterpart (msm_ioctl_gem_info_set_metadata) correctly returns ret. Patchwork: https://patchwork.freedesktop.org/patch/714478/", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46200", "url": "https://ubuntu.com/security/CVE-2026-46200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix controller deregistration Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and gpios during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46241", "url": "https://ubuntu.com/security/CVE-2026-46241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on registration failure Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46214", "url": "https://ubuntu.com/security/CVE-2026-46214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46234", "url": "https://ubuntu.com/security/CVE-2026-46234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-23171", "url": "https://ubuntu.com/security/CVE-2026-23171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix use-after-free due to enslave fail after slave array update Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems. It is very easy to reproduce the problem with a simple xdp_pass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass ip l add dumdum type dummy Then run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp \"dp=1-1023, flags=syn\" The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BAD_PAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] [ 605.603410] __dev_queue_xmit+0x448/0x32a0 [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10 [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10 [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603546] ? _printk+0xcb/0x100 [ 605.603566] ? __pfx__printk+0x10/0x10 [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603627] ? add_taint+0x5e/0x70 [ 605.603648] ? add_taint+0x2a/0x70 [ 605.603670] ? end_report.cold+0x51/0x75 [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding] [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]", "cve_priority": "high", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-45836", "url": "https://ubuntu.com/security/CVE-2026-45836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46111", "url": "https://ubuntu.com/security/CVE-2026-46111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in create_big_sync Add hci_conn_valid() check in create_big_sync() to detect stale connections before proceeding with BIG creation. Handle the resulting -ECANCELED in create_big_complete() and re-validate the connection under hci_dev_lock() before dereferencing, matching the pattern used by create_le_conn_complete() and create_pa_complete(). Keep the hci_conn object alive across the async boundary by taking a reference via hci_conn_get() when queueing create_big_sync(), and dropping it in the completion callback. The refcount and the lock are complementary: the refcount keeps the object allocated, while hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on hdev->conn_hash, as required by hci_conn_del(). hci_conn_put() is called outside hci_dev_unlock() so the final put (which resolves to kfree() via bt_link_release) does not run under hdev->lock, though the release path would be safe either way. Without this, create_big_complete() would unconditionally dereference the conn pointer on error, causing a use-after-free via hci_connect_cfm() and hci_conn_del().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46044", "url": "https://ubuntu.com/security/CVE-2026-46044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:ssif: Clean up kthread on errors If an error occurs after the ssif kthread is created, but before the main IPMI code starts the ssif interface, the ssif kthread will not be stopped. So make sure the kthread is stopped on an error condition if it is running.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46231", "url": "https://ubuntu.com/security/CVE-2026-46231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46233", "url": "https://ubuntu.com/security/CVE-2026-46233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46212", "url": "https://ubuntu.com/security/CVE-2026-46212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46238", "url": "https://ubuntu.com/security/CVE-2026-46238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46206", "url": "https://ubuntu.com/security/CVE-2026-46206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46198", "url": "https://ubuntu.com/security/CVE-2026-46198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46227", "url": "https://ubuntu.com/security/CVE-2026-46227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the \"sk != asoc->base.sk\" and \"asoc->base.dead\" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 (\"sctp: walk the list of asoc safely\") was added for.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46220", "url": "https://ubuntu.com/security/CVE-2026-46220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46197", "url": "https://ubuntu.com/security/CVE-2026-46197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46209", "url": "https://ubuntu.com/security/CVE-2026-46209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46230", "url": "https://ubuntu.com/security/CVE-2026-46230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46199", "url": "https://ubuntu.com/security/CVE-2026-46199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46204", "url": "https://ubuntu.com/security/CVE-2026-46204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46218", "url": "https://ubuntu.com/security/CVE-2026-46218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add bounds checking to ib_{get,set}_value The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46229", "url": "https://ubuntu.com/security/CVE-2026-46229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels. The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers. This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46219", "url": "https://ubuntu.com/security/CVE-2026-46219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46225", "url": "https://ubuntu.com/security/CVE-2026-46225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: rspi: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46226", "url": "https://ubuntu.com/security/CVE-2026-46226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46235", "url": "https://ubuntu.com/security/CVE-2026-46235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7164: add ioremap return checks and cleanups Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46312", "url": "https://ubuntu.com/security/CVE-2026-46312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops. gst-launch-1.0 v4l2src ! gtk4paintablesink [ 38.201528] ------------[ cut here ]------------ [ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [ 38.219040] Tainted: [W]=WARN [ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp : ffffc0008dc678e0 [ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [ 38.231488] Call trace: [ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [ 38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813] __mmap_region+0x488/0x9a0 [ 38.233277] mmap_region+0xd0/0x148 [ 38.233703] do_mmap+0x350/0x5c0 [ 38.234148] vm_mmap_pgoff+0x14c/0x200 [ 38.234612] ksys_mmap_pgoff+0x150/0x208 [ 38.235107] __arm64_sys_mmap+0x34/0x50 [ 38.235611] invoke_syscall+0x50/0x120 [ 38.236075] el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680] do_el0_svc+0x24/0x38 [ 38.237113] el0_svc+0x38/0x168 [ 38.237507] el0t_64_sync_handler+0xa0/0xe8 [ 38.238034] el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end trace 0000000000000000 ]--- There were discussions in [1] at the end of 2023 that mmap() on imported ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46236", "url": "https://ubuntu.com/security/CVE-2026-46236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46205", "url": "https://ubuntu.com/security/CVE-2026-46205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46232", "url": "https://ubuntu.com/security/CVE-2026-46232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Clamp num_touch_reports A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43490", "url": "https://ubuntu.com/security/CVE-2026-43490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate inherited ACE SID length smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.num_subauth is fully contained in the ACE. A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. compare_sids() may then read past the ACE. smb_set_ace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and nt_size accounting past the allocated buffer. Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smb_acl.size or the security descriptor allocation size.", "cve_priority": "high", "cve_public_date": "2026-05-15 06:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46110", "url": "https://ubuntu.com/security/CVE-2026-46110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag (\"OWN\") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both \"submissions\" and \"completions.\" In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46007", "url": "https://ubuntu.com/security/CVE-2026-46007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Avoid cacheline sharing for DMA buffer Depending on the architecture the transfer buffer may share a cacheline with the following mutex. As the buffer may be used for DMA, that is problematic. Use the high-level DMA helpers to make sure that cacheline sharing can not happen. Also drop the comment, as the helpers are documentation enough. https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46194", "url": "https://ubuntu.com/security/CVE-2026-46194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix node_cnt race between extent node destroy and writeback f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing extent nodes. When called from f2fs_drop_inode() with I_SYNC set, concurrent kworker writeback can insert new extent nodes into the same extent tree, racing with the destroy and triggering f2fs_bug_on() in __destroy_extent_node(). The scenario is as follows: drop inode writeback - iput - f2fs_drop_inode // I_SYNC set - f2fs_destroy_extent_node - __destroy_extent_node - while (node_cnt) { write_lock(&et->lock) __free_extent_tree write_unlock(&et->lock) - __writeback_single_inode - f2fs_outplace_write_data - f2fs_update_read_extent_cache - __update_extent_tree_range // FI_NO_EXTENT not set, // insert new extent node } // node_cnt == 0, exit while - f2fs_bug_on(node_cnt) // node_cnt > 0 Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected. This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(), consistent with other callers (__update_extent_tree_range and __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and EX_BLOCK_AGE tree.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46168", "url": "https://ubuntu.com/security/CVE-2026-46168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46189", "url": "https://ubuntu.com/security/CVE-2026-46189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46133", "url": "https://ubuntu.com/security/CVE-2026-46133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 (\"RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv\"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and \"rdma link add\"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46114", "url": "https://ubuntu.com/security/CVE-2026-46114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt); check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path. Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46127", "url": "https://ubuntu.com/security/CVE-2026-46127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46176", "url": "https://ubuntu.com/security/CVE-2026-46176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTR s1 to devr->s0 and devr->s1. This leads to several problems: the lock-free fast path checks \"if (devr->s1) return 0;\" and treats the ERR_PTR as already initialised; users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR and double-frees s0 on teardown. Fix by adding the same `goto unlock` in the s1 failure path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46178", "url": "https://ubuntu.com/security/CVE-2026-46178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46145", "url": "https://ubuntu.com/security/CVE-2026-46145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46126", "url": "https://ubuntu.com/security/CVE-2026-46126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound. First there is a double i-- on the first failure path due to the while loop having a i--, remove it. Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not undone due to the above i--.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46144", "url": "https://ubuntu.com/security/CVE-2026-46144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46121", "url": "https://ubuntu.com/security/CVE-2026-46121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock Patch series \"mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path\". Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those. This patch (of 2): damon_sysfs_scheme_filter->mmecg_path can be read and written by users, via DAMON sysfs memcg_path file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcg_path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46131", "url": "https://ubuntu.com/security/CVE-2026-46131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: check for nEPT/nNPT in slow flush hypercalls Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46139", "url": "https://ubuntu.com/security/CVE-2026-46139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d (\"smb: common: change the data type of num_aces to le16\") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with \"ndr_pull_security_descriptor failed: Range Error\", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46112", "url": "https://ubuntu.com/security/CVE-2026-46112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46304", "url": "https://ubuntu.com/security/CVE-2026-46304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). If that triggers nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on the same nvmet-wq. Call chain: nvmet_tcp_schedule_release_queue() kref_put(&queue->kref, nvmet_tcp_release_queue) nvmet_tcp_release_queue() queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq process_one_work() nvmet_tcp_release_queue_work() nvmet_cq_put(&queue->nvme_cq) nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl) nvmet_ctrl_free() flush_work(&ctrl->async_event_work) <--- nvmet_wq Previously Scheduled by :- \t\t nvmet_add_async_event \t\t queue_work(nvmet_wq, &ctrl->async_event_work); This trips lockdep with a possible recursive locking warning. [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN \"nqn.2014-08.org.nvmexpress.discovery\" [ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario: [ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wq_completion)nvmet-wq); [ 5233.275241] lock((wq_completion)nvmet-wq); [ 5233.278020] *** DEADLOCK *** [ 5233.281793] May be due to missing lock nesting notation [ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp] [ 5233.306532] Call Trace: [ 5233.306534] [ 5233.306536] dump_stack_lvl+0x73/0xb0 [ 5233.306552] print_deadlock_bug+0x225/0x2f0 [ 5233.306556] __lock_acquire+0x13f0/0x2290 [ 5233.306563] lock_acquire+0xd0/0x300 [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ? __flush_work+0x20b/0x530 [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90 [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90 [ 52 ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46135", "url": "https://ubuntu.com/security/CVE-2026-46135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.", "cve_priority": "critical", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46161", "url": "https://ubuntu.com/security/CVE-2026-46161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the \"improved\" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-46124", "url": "https://ubuntu.com/security/CVE-2026-46124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 (\"isofs: Prevent the use of too small fid\") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46303", "url": "https://ubuntu.com/security/CVE-2026-46303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b (\"[PATCH] rock.c: handle corrupted directories\") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 (\"isofs: Fix infinite looping over CE entries\") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46106", "url": "https://ubuntu.com/security/CVE-2026-46106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventfs: Hold eventfs_mutex and SRCU when remount walks events Commit 340f0c7067a9 (\"eventfs: Update all the eventfs_inodes from the events descriptor\") had eventfs_set_attrs() recurse through ei->children on remount. The walk only holds the rcu_read_lock() taken by tracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex. Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo \"p:kp submit_bio\" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done Wrap the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() that take eventfs_mutex and srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract. Comment in tracefs_drop_inode() said \"RCU cycle\" -- it is SRCU.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46294", "url": "https://ubuntu.com/security/CVE-2026-46294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the \"outptr\" variable to the next 8-byte boundary: \toutptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The \"for\" loop is iterated again, it executes: \tremaining = len - (outptr - outbuf); 5. If \"outptr\" points past \"outbuf + len\", the arithmetics wraps around and the variable \"remaining\" contains unusually high number 6. With \"remaining\" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, \"outptr = align_ptr(outptr)\" can't overshoot the input buffer and the bug can't happen accidentally", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46107", "url": "https://ubuntu.com/security/CVE-2026-46107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in \"device mapper: space map common: unable to decrement block\" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46129", "url": "https://ubuntu.com/security/CVE-2026-46129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info() error path When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46143", "url": "https://ubuntu.com/security/CVE-2026-46143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46293", "url": "https://ubuntu.com/security/CVE-2026-46293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: microchip: mpfs-ccc: fix out of bounds access during output registration UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46301", "url": "https://ubuntu.com/security/CVE-2026-46301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46273", "url": "https://ubuntu.com/security/CVE-2026-46273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit (\"ibmvnic: Enforce stronger sanity checks on GSO packets\") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability).", "cve_priority": "high", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43495", "url": "https://ubuntu.com/security/CVE-2026-43495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as a loop bound over port_msg->data[] without checking that the message buffer contains sufficient data. A modem sending port_count=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes. Add a sizeof(*port_msg) check before accessing the port message header fields to guard against undersized messages. Add a struct_size() check after extracting port_count and before the loop. In t7xx_parse_host_rt_data(), guard the rt_feature header read with a remaining-buffer check before accessing data_len, validate feat_data_len against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset. Pass msg_len from both call sites: skb->len at the DPMAIF path after skb_pull(), and the validated feat_data_len at the handshake path.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-43502", "url": "https://ubuntu.com/security/CVE-2026-43502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46120", "url": "https://ubuntu.com/security/CVE-2026-46120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 (\"net: ipv6: Use link netns in newlink() of rtnl_link_ops\"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46142", "url": "https://ubuntu.com/security/CVE-2026-46142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix VF illegal register access Register WX_CFG_PORT_ST is a PF restricted register. When a VF is initialized, attempting to read this register triggers an illegal register access, which lead to a system hang. When the device is VF, the bus function ID can be obtained directly from the PCI_FUNC(pdev->devfn).", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46184", "url": "https://ubuntu.com/security/CVE-2026-46184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46132", "url": "https://ubuntu.com/security/CVE-2026-46132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: \tstruct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: \t/* include/uapi/linux/if_link.h */ \tstruct ifla_vf_broadcast { \t\t__u8 broadcast[32]; \t}; The function then copies dev->broadcast into it using dev->addr_len as the length: \tmemcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: \tnla_put(skb, IFLA_VF_BROADCAST, \t\tsizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46190", "url": "https://ubuntu.com/security/CVE-2026-46190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show() Sashiko noticed an out-of-bounds read [1]. In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names). Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers \t(element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended. Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count. Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46150", "url": "https://ubuntu.com/security/CVE-2026-46150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46296", "url": "https://ubuntu.com/security/CVE-2026-46296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: s3c64xx: fix NULL-deref on driver unbind A change moving DMA channel allocation from probe() back to s3c64xx_spi_prepare_transfer() failed to remove the corresponding deallocation from remove(). Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind. This issue was flagged by Sashiko when reviewing a controller deregistration fix.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-45834", "url": "https://ubuntu.com/security/CVE-2026-45834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-45835", "url": "https://ubuntu.com/security/CVE-2026-45835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().", "cve_priority": "medium", "cve_public_date": "2026-05-26 17:16:00 UTC" }, { "cve": "CVE-2026-46138", "url": "https://ubuntu.com/security/CVE-2026-46138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access. When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held. Fix this by terminating the BIG if in case not all BIS could be setup properly.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46186", "url": "https://ubuntu.com/security/CVE-2026-46186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46123", "url": "https://ubuntu.com/security/CVE-2026-46123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened the USB 9p transport against unchecked device-reported length.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46172", "url": "https://ubuntu.com/security/CVE-2026-46172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46157", "url": "https://ubuntu.com/security/CVE-2026-46157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46146", "url": "https://ubuntu.com/security/CVE-2026-46146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46167", "url": "https://ubuntu.com/security/CVE-2026-46167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send \"incorrect\" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no \"leak\" of information happening.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46151", "url": "https://ubuntu.com/security/CVE-2026-46151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf(\"%s\", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46122", "url": "https://ubuntu.com/security/CVE-2026-46122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46125", "url": "https://ubuntu.com/security/CVE-2026-46125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any \"new_sta\" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46307", "url": "https://ubuntu.com/security/CVE-2026-46307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath5k: do not access array OOB Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46187", "url": "https://ubuntu.com/security/CVE-2026-46187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46152", "url": "https://ubuntu.com/security/CVE-2026-46152", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46163", "url": "https://ubuntu.com/security/CVE-2026-46163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46136", "url": "https://ubuntu.com/security/CVE-2026-46136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix a potential clc buffer length underflow The buf_len is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC. This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46173", "url": "https://ubuntu.com/security/CVE-2026-46173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying \"WARNING: must be called with preemption disabled!\". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect \"recursively oopsing\" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31499", "url": "https://ubuntu.com/security/CVE-2026-31499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del() l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock. Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43496", "url": "https://ubuntu.com/security/CVE-2026-43496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead.", "cve_priority": "medium", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-43088", "url": "https://ubuntu.com/security/CVE-2026-43088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-46287", "url": "https://ubuntu.com/security/CVE-2026-46287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix RTNL assertion warning when remove module For the copper NIC with external PHY, the driver called phylink_connect_phy() during probe and phylink_disconnect_phy() during remove. It caused an RTNL assertion warning in phylink_disconnect_phy() upon module remove. To fix this, add rtnl_lock() and rtnl_unlock() around the phylink_disconnect_phy() in remove function. ------------[ cut here ]------------ RTNL: assertion failed at drivers/net/phy/phylink.c (2351) WARNING: drivers/net/phy/phylink.c:2351 at phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464 Modules linked in: ... CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+ Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink] Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000 RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020 RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000 R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348 FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: txgbe_remove_phy+0xbb/0xd0 [txgbe] txgbe_remove+0x4c/0xb0 [txgbe] pci_device_remove+0x41/0xb0 device_remove+0x43/0x80 device_release_driver_internal+0x206/0x270 driver_detach+0x4a/0xa0 bus_remove_driver+0x83/0x120 driver_unregister+0x2f/0x60 pci_unregister_driver+0x40/0x90 txgbe_driver_exit+0x10/0x850 [txgbe] __do_sys_delete_module.isra.0+0x1c3/0x2f0 __x64_sys_delete_module+0x12/0x20 x64_sys_call+0x20c3/0x2390 do_syscall_64+0x11c/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x15a/0x1500 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_fault+0x312/0x580 ? srso_alias_return_thunk+0x5/0xfbef5 ? __handle_mm_fault+0x9d5/0x1040 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events+0x101/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1e8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x2f8/0x820 ? srso_alias_return_thunk+0x5/0xfbef5 ? irqentry_exit+0xb2/0x600 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46306", "url": "https://ubuntu.com/security/CVE-2026-46306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: flow_dissector: do not dissect PPPoE PFC frames RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the flow dissector driver has assumed an uncompressed frame until the blamed commit. During the review process of that commit [1], support for PFC is suggested. However, having a compressed (1-byte) protocol field means the subsequent PPP payload is shifted by one byte, causing 4-byte misalignment for the network header and an unaligned access exception on some architectures. The exception can be reproduced by sending a PPPoE PFC frame to an ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE session is active on that interface: $ 0 : 00000000 80c40000 00000000 85144817 $ 4 : 00000008 00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c 0000003d 00000000 $12 : 000000e0 00000039 00000000 00000000 $16 : 85043240 80a75758 81dc9bb8 00006488 $20 : 0000002f 00000007 85144810 80a70000 $24 : 81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000 805ead08 Hi : 00009d51 Lo : 2163358a epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra : 805ead08 __skb_get_hash_net+0x74/0x12c Status: 11000403 KERNEL EXL IE Cause : 40800010 (ExcCode 04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc) Call Trace: [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50 [<805ead08>] __skb_get_hash_net+0x74/0x12c [<805ef330>] get_rps_cpu+0x1b8/0x3fc [<805fca70>] netif_receive_skb_list_internal+0x324/0x364 [<805fd120>] napi_complete_done+0x68/0x2a4 [<8058de5c>] mtk_napi_rx+0x228/0xfec [<805fd398>] __napi_poll+0x3c/0x1c4 [<805fd754>] napi_threaded_poll_loop+0x234/0x29c [<805fd848>] napi_threaded_poll+0x8c/0xb0 [<80053544>] kthread+0x104/0x12c [<80002bd8>] ret_from_kernel_thread+0x14/0x1c Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000 To reduce the attack surface and maintain performance, do not process PPPoE PFC frames. [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46113", "url": "https://ubuntu.com/security/CVE-2026-46113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, \"KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE\", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the \"correct\" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the \"wrong\" shadow page. However, that was only an imprecision until 2032a93d66fa (\"KVM: MMU: Don't allocate gfns page for direct mmu pages\") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46063", "url": "https://ubuntu.com/security/CVE-2026-46063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/shstk: Prevent deadlock during shstk sigreturn During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43109", "url": "https://ubuntu.com/security/CVE-2026-43109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86: shadow stacks: proper error handling for mmap lock 김영민 reports that shstk_pop_sigframe() doesn't check for errors from mmap_read_lock_killable(), which is a silly oversight, and also shows that we haven't marked those functions with \"__must_check\", which would have immediately caught it. So let's fix both issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-46179", "url": "https://ubuntu.com/security/CVE-2026-46179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Don't allow pointer operations on unconfigured streams When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43497", "url": "https://ubuntu.com/security/CVE-2026-43497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.", "cve_priority": "low", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46108", "url": "https://ubuntu.com/security/CVE-2026-46108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46128", "url": "https://ubuntu.com/security/CVE-2026-46128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46177", "url": "https://ubuntu.com/security/CVE-2026-46177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46149", "url": "https://ubuntu.com/security/CVE-2026-46149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea (\"scsi: target: target_core_configfs: Add length check to avoid buffer overflow\") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46101", "url": "https://ubuntu.com/security/CVE-2026-46101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46099", "url": "https://ubuntu.com/security/CVE-2026-46099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46276", "url": "https://ubuntu.com/security/CVE-2026-46276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix zero-size GDS range init on RDNA4 RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d)", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46033", "url": "https://ubuntu.com/security/CVE-2026-46033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46083", "url": "https://ubuntu.com/security/CVE-2026-46083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fix resource leaks on device setup failure Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-46282", "url": "https://ubuntu.com/security/CVE-2026-46282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: frequency: admv1013: fix NULL pointer dereference on str When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46084", "url": "https://ubuntu.com/security/CVE-2026-46084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: Disable RX steering on RSS QP destroy When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss() destroys the RX WQ objects but does not disable vPort RX steering in firmware. This leaves stale steering configuration that still points to the destroyed RX objects. If traffic continues to arrive (e.g. peer VM is still transmitting) and the VF interface is subsequently brought up (mana_open), the firmware may deliver completions using stale CQ IDs from the old RX objects. These CQ IDs can be reused by the ethernet driver for new TX CQs, causing RX completions to land on TX CQs: WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false) WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails) Fix this by disabling vPort RX steering before destroying RX WQ objects. Note that mana_fence_rqs() cannot be used here because the fence completion is delivered on the CQ, which is polled by user-mode (e.g. DPDK) and not visible to the kernel driver. Refactor the disable logic into a shared mana_disable_vport_rx() in mana_en, exported for use by mana_ib, replacing the duplicate code. The ethernet driver's mana_dealloc_queues() is also updated to call this common function.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46280", "url": "https://ubuntu.com/security/CVE-2026-46280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: test_hmm: evict device pages on file close to avoid use-after-free Patch series \"Minor hmm_test fixes and cleanups\". Two bugfixes a cleanup for the HMM kernel selftests. These were mostly reported by Zenghui Yu with special thanks to Lorenzo for analysing and pointing out the problems. This patch (of 3): When dmirror_fops_release() is called it frees the dmirror struct but doesn't migrate device private pages back to system memory first. This leaves those pages with a dangling zone_device_data pointer to the freed dmirror. If a subsequent fault occurs on those pages (eg. during coredump) the dmirror_devmem_fault() callback dereferences the stale pointer causing a kernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64, where a test failure triggered SIGABRT and the resulting coredump walked the VMAs faulting in the stale device private pages. Fix this by calling dmirror_device_evict_chunk() for each devmem chunk in dmirror_fops_release() to migrate all device private pages back to system memory before freeing the dmirror struct. The function is moved earlier in the file to avoid a forward declaration.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-45997", "url": "https://ubuntu.com/security/CVE-2026-45997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46062", "url": "https://ubuntu.com/security/CVE-2026-46062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 (\"ntfs3: Fix integer overflow in run_unpack()\"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46072", "url": "https://ubuntu.com/security/CVE-2026-46072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46023", "url": "https://ubuntu.com/security/CVE-2026-46023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46075", "url": "https://ubuntu.com/security/CVE-2026-46075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46077", "url": "https://ubuntu.com/security/CVE-2026-46077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45986", "url": "https://ubuntu.com/security/CVE-2026-45986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46019", "url": "https://ubuntu.com/security/CVE-2026-46019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46015", "url": "https://ubuntu.com/security/CVE-2026-46015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46040", "url": "https://ubuntu.com/security/CVE-2026-46040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff (\"inotify: Convert to using per-namespace limits\"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46070", "url": "https://ubuntu.com/security/CVE-2026-46070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46051", "url": "https://ubuntu.com/security/CVE-2026-46051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46046", "url": "https://ubuntu.com/security/CVE-2026-46046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 (\"ext4: ignore xattrs past end\") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46094", "url": "https://ubuntu.com/security/CVE-2026-46094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46076", "url": "https://ubuntu.com/security/CVE-2026-46076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining \"single\" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46082", "url": "https://ubuntu.com/security/CVE-2026-46082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45987", "url": "https://ubuntu.com/security/CVE-2026-45987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46005", "url": "https://ubuntu.com/security/CVE-2026-46005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix a resource leak in xfs_alloc_buftarg() In the error path, call fs_put_dax() to drop the DAX device reference.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46024", "url": "https://ubuntu.com/security/CVE-2026-46024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46037", "url": "https://ubuntu.com/security/CVE-2026-46037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46031", "url": "https://ubuntu.com/security/CVE-2026-46031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Reinstate disabling of BHs around IRQ handler If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 (\"net: ks8851: Fix deadlock with the SPI chip variant\") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46027", "url": "https://ubuntu.com/security/CVE-2026-46027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46053", "url": "https://ubuntu.com/security/CVE-2026-46053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46012", "url": "https://ubuntu.com/security/CVE-2026-46012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix memory leaks in rxkad_verify_response() Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46004", "url": "https://ubuntu.com/security/CVE-2026-46004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46079", "url": "https://ubuntu.com/security/CVE-2026-46079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: fix null-ptr-deref when device_add_disk() fails do_rbd_add() publishes the device with device_add() before calling device_add_disk(). If device_add_disk() fails after device_add() succeeds, the error path calls rbd_free_disk() directly and then later falls through to rbd_dev_device_release(), which calls rbd_free_disk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set(). Fix this by following the normal remove ordering: call device_del() before rbd_dev_device_release() when device_add_disk() fails after device_add(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong 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. We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer confines failslab injections to the __add_disk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/add_single_major. On the unpatched kernel, fail-nth=4 reliably triggered the fault: \tOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI \tKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \tCPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tRIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240 \tCode: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 \tRSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 \tRAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 \tRDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 \tRBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b \tR10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 \tR13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 \tFS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 \tCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 \tCR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 \tPKRU: 55555554 \tCall Trace: \t \t blk_mq_free_tag_set+0x77/0x460 \t do_rbd_add+0x1446/0x2b80 \t ? __pfx_do_rbd_add+0x10/0x10 \t ? lock_acquire+0x18c/0x300 \t ? find_held_lock+0x2b/0x80 \t ? sysfs_file_kobj+0xb6/0x1b0 \t ? __pfx_sysfs_kf_write+0x10/0x10 \t kernfs_fop_write_iter+0x2f4/0x4a0 \t vfs_write+0x98e/0x1000 \t ? expand_files+0x51f/0x850 \t ? __pfx_vfs_write+0x10/0x10 \t ksys_write+0xf2/0x1d0 \t ? __pfx_ksys_write+0x10/0x10 \t do_syscall_64+0x115/0x690 \t entry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7f0fbea15907 \tCode: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 \tRSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 \tRAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 \tRDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 \tRBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 \tR10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 \tR13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 \t With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports. [ idryomov: rename err_out_device_del -> err_out_device ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46016", "url": "https://ubuntu.com/security/CVE-2026-46016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: xlnx: Only access buffer information if IPI is buffered In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46285", "url": "https://ubuntu.com/security/CVE-2026-46285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46050", "url": "https://ubuntu.com/security/CVE-2026-46050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf \tbarrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46061", "url": "https://ubuntu.com/security/CVE-2026-46061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix deadlock in jbd2_journal_cancel_revoke() Commit f76d4c28a46a (\"fs/jbd2: use sleeping version of __find_get_block()\") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A This can occasionally cause generic/013 to hang. Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46049", "url": "https://ubuntu.com/security/CVE-2026-46049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46002", "url": "https://ubuntu.com/security/CVE-2026-46002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget() ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is zero or i_dtime is set, treating them as deleted. However, the case of i_nlink == 0 with a non-zero mode and zero dtime slips through. Since ext2 has no orphan list, such a combination can only result from filesystem corruption - a legitimate inode deletion always sets either i_dtime or clears i_mode before freeing the inode. A crafted image can exploit this gap to present such an inode to the VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via ext2_unlink(), ext2_rename() and ext2_rmdir(): WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295 vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477 do_unlinkat+0x53e/0x730 fs/namei.c:4541 __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rename+0x35e/0x850 fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060 fs/namei.c:5021 do_renameat2+0xbe2/0xd50 fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336 CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1 Call Trace: inode_dec_link_count include/linux/fs.h:2518 [inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311 vfs_rmdir+0x204/0x690 fs/namei.c:4348 do_rmdir+0x372/0x3e0 fs/namei.c:4407 __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577 do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Extend the existing i_nlink == 0 check to also catch this case, reporting the corruption via ext2_error() and returning -EFSCORRUPTED. This rejects the inode at load time and prevents it from reaching any of the namei.c paths. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46047", "url": "https://ubuntu.com/security/CVE-2026-46047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46009", "url": "https://ubuntu.com/security/CVE-2026-46009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46011", "url": "https://ubuntu.com/security/CVE-2026-46011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: fix use-after-free in release path due to uncancelled work The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46102", "url": "https://ubuntu.com/security/CVE-2026-46102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46098", "url": "https://ubuntu.com/security/CVE-2026-46098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46088", "url": "https://ubuntu.com/security/CVE-2026-46088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46058", "url": "https://ubuntu.com/security/CVE-2026-46058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: amphion: Fix race between m2m job_abort and device_run Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46073", "url": "https://ubuntu.com/security/CVE-2026-46073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when interrupted. This needs to abort the URB and return an error. No data has been received from the device so any reads from the transfer buffer are invalid. The original code tests !ret, which only catches the timeout case (0). On signal delivery (-ERESTARTSYS), !ret is false so the function skips usb_kill_urb() and falls through to read from the unfilled transfer buffer. Fix by capturing the return value into a long (matching the function return type) and handling signal (negative) and timeout (zero) cases with separate checks that both call usb_kill_urb() before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45989", "url": "https://ubuntu.com/security/CVE-2026-45989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: of: unittest: fix use-after-free in testdrv_probe() The function testdrv_probe() retrieves the device_node from the PCI device, applies an overlay, and then immediately calls of_node_put(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to of_platform_default_populate(), leading to a use-after-free. The reference to pdev->dev.of_node is owned by the device model and should not be released by the driver. Remove the erroneous of_node_put() to prevent premature freeing.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45996", "url": "https://ubuntu.com/security/CVE-2026-45996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix use-after-free on unbind The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed). Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46089", "url": "https://ubuntu.com/security/CVE-2026-46089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: do not forget to endio for partial discard requests As reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 takes literally forever to complete. zram doesn't support partial discards and just returns immediately w/o doing any discard work in such cases. The problem is that we forget to endio on our way out, so blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to end_bio label, which does bio_endio().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46080", "url": "https://ubuntu.com/security/CVE-2026-46080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-23468", "url": "https://ubuntu.com/security/CVE-2026-23468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-46064", "url": "https://ubuntu.com/security/CVE-2026-46064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45994", "url": "https://ubuntu.com/security/CVE-2026-45994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46022", "url": "https://ubuntu.com/security/CVE-2026-46022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46041", "url": "https://ubuntu.com/security/CVE-2026-46041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger \"BUG: scheduling while atomic\". Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow: 1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46286", "url": "https://ubuntu.com/security/CVE-2026-46286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: qcom-lpg: Check for array overflow when selecting the high resolution When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46006", "url": "https://ubuntu.com/security/CVE-2026-46006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45993", "url": "https://ubuntu.com/security/CVE-2026-45993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add spectre boundry for syscall dispatch table The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46018", "url": "https://ubuntu.com/security/CVE-2026-46018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints \"invalid uac2 rates\" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2025-54518", "url": "https://ubuntu.com/security/CVE-2025-54518", "cve_description": "Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.", "cve_priority": "high", "cve_public_date": "2026-05-15 05:16:00 UTC" }, { "cve": "CVE-2026-46174", "url": "https://ubuntu.com/security/CVE-2026-46174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31706", "url": "https://ubuntu.com/security/CVE-2026-31706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory's DACL xattr and uses it to size a heap allocation: aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...); num_aces is a u16 read from le16_to_cpu(parent_pdacl->num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory's security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data. This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels. Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum. Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()'s hash check still passes. A subsequent SMB2 CREATE of a child under that parent drives smb2_open() into smb_inherit_dacl() (share has \"vfs objects = acl_xattr\" set), which fails the page allocator: WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0 Workqueue: ksmbd-io handle_ksmbd_work __alloc_frozen_pages_noprof+0x46c/0x9c0 ___kmalloc_large_node+0x68/0x130 __kmalloc_large_node_noprof+0x24/0x70 __kmalloc_noprof+0x4c9/0x690 smb_inherit_dacl+0x394/0x2430 smb2_open+0x595d/0xabe0 handle_ksmbd_work+0x3d3/0x1140 With the patch applied the added guard rejects the tampered value with -EINVAL before any large allocation runs, smb2_open() falls back to smb2_create_sd_buffer(), and the child is created with a default SD. No warning, no splat. Fix by: 1. Validating num_aces against pdacl_size using the same formula applied in parse_dacl(). 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe allocation. 3. Tightening the per-ACE loop guard to require the minimum valid ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and rejecting under-sized ACEs, matching the hardening in smb_check_perm_dacl() and parse_dacl(). v1 -> v2: - Replace the synthetic test-module splat in the changelog with a real-path UML + KASAN reproduction driven through mount.cifs and SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name in v1 since it does not exist in ksmbd. - Drop the commit-hash citation from the code comment per Namjae's review; keep the parse_dacl() pointer.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31575", "url": "https://ubuntu.com/security/CVE-2026-31575", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix hugetlb fault mutex hash calculation In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31582", "url": "https://ubuntu.com/security/CVE-2026-31582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Fix use-after-free on USB disconnect After powerz_disconnect() frees the URB and releases the mutex, a subsequent powerz_read() call can acquire the mutex and call powerz_read_data(), which dereferences the freed URB pointer. Fix by: - Setting priv->urb to NULL in powerz_disconnect() so that powerz_read_data() can detect the disconnected state. - Adding a !priv->urb check at the start of powerz_read_data() to return -ENODEV on a disconnected device. - Moving usb_set_intfdata() before hwmon registration so the disconnect handler can always find the priv pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43073", "url": "https://ubuntu.com/security/CVE-2026-43073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86-64: rename misleadingly named '__copy_user_nocache()' function This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal \"start user space access\" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-21709", "url": "https://ubuntu.com/security/CVE-2025-21709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel: be more careful about dup_mmap() failures and uprobe registering If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f (\"fork: avoid inappropriate uprobe access to invalid mm\") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised.", "cve_priority": "medium", "cve_public_date": "2025-02-27 02:15:00 UTC" }, { "cve": "CVE-2026-31606", "url": "https://ubuntu.com/security/CVE-2026-31606", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: don't call cdev_init while cdev in use When calling unbind, then bind again, cdev_init reinitialized the cdev, even though there may still be references to it. That's the case when the /dev/hidg* device is still opened. This obviously unsafe behavior like oopes. This fixes this by using cdev_alloc to put the cdev on the heap. That way, we can simply allocate a new one in hidg_bind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31731", "url": "https://ubuntu.com/security/CVE-2026-31731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Address thermal zone removal races with resume Since thermal_zone_pm_complete() and thermal_zone_device_resume() re-initialize the poll_queue delayed work for the given thermal zone, the cancel_delayed_work_sync() in thermal_zone_device_unregister() may miss some already running work items and the thermal zone may be freed prematurely [1]. There are two failing scenarios that both start with running thermal_pm_notify_complete() right before invoking thermal_zone_device_unregister() for one of the thermal zones. In the first scenario, there is a work item already running for the given thermal zone when thermal_pm_notify_complete() calls thermal_zone_pm_complete() for that thermal zone and it continues to run when thermal_zone_device_unregister() starts. Since the poll_queue delayed work has been re-initialized by thermal_pm_notify_complete(), the running work item will be missed by the cancel_delayed_work_sync() in thermal_zone_device_unregister() and if it continues to run past the freeing of the thermal zone object, a use-after-free will occur. In the second scenario, thermal_zone_device_resume() queued up by thermal_pm_notify_complete() runs right after the thermal_zone_exit() called by thermal_zone_device_unregister() has returned. The poll_queue delayed work is re-initialized by it before cancel_delayed_work_sync() is called by thermal_zone_device_unregister(), so it may continue to run after the freeing of the thermal zone object, which also leads to a use-after-free. Address the first failing scenario by ensuring that no thermal work items will be running when thermal_pm_notify_complete() is called. For this purpose, first move the cancel_delayed_work() call from thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent new work from entering the workqueue going forward. Next, switch over to using a dedicated workqueue for thermal events and update the code in thermal_pm_notify() to flush that workqueue after thermal_pm_notify_prepare() has returned which will take care of all leftover thermal work already on the workqueue (that leftover work would do nothing useful anyway because all of the thermal zones have been flagged as suspended). The second failing scenario is addressed by adding a tz->state check to thermal_zone_device_resume() to prevent it from re-initializing the poll_queue delayed work if the thermal zone is going away. Note that the above changes will also facilitate relocating the suspend and resume of thermal zones closer to the suspend and resume of devices, respectively.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31677", "url": "https://ubuntu.com/security/CVE-2026-31677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43107", "url": "https://ubuntu.com/security/CVE-2026-43107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: account XFRMA_IF_ID in aevent size calculation xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set. xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic. Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43119", "url": "https://ubuntu.com/security/CVE-2026-43119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering).", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31696", "url": "https://ubuntu.com/security/CVE-2026-31696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing validation of ticket length in non-XDR key preparsing In rxrpc_preparse(), there are two paths for parsing key payloads: the XDR path (for large payloads) and the non-XDR path (for payloads <= 28 bytes). While the XDR path (rxrpc_preparse_xdr_rxkad()) correctly validates the ticket length against AFSTOKEN_RK_TIX_MAX, the non-XDR path fails to do so. This allows an unprivileged user to provide a very large ticket length. When this key is later read via rxrpc_read(), the total token size (toksize) calculation results in a value that exceeds AFSTOKEN_LENGTH_MAX, triggering a WARN_ON(). [ 2001.302904] WARNING: CPU: 2 PID: 2108 at net/rxrpc/key.c:778 rxrpc_read+0x109/0x5c0 [rxrpc] Fix this by adding a check in the non-XDR parsing path of rxrpc_preparse() to ensure the ticket length does not exceed AFSTOKEN_RK_TIX_MAX, bringing it into parity with the XDR parsing logic.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31697", "url": "https://ubuntu.com/security/CVE-2026-31697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31698", "url": "https://ubuntu.com/security/CVE-2026-31698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31699", "url": "https://ubuntu.com/security/CVE-2026-31699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failed When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31701", "url": "https://ubuntu.com/security/CVE-2026-31701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: take a reference on the USB device in create_card() The caiaq driver stores a pointer to the parent USB device in cdev->chip.dev but never takes a reference on it. The card's private_free callback, snd_usb_caiaq_card_free(), can run asynchronously via snd_card_free_when_closed() after the USB device has already been disconnected and freed, so any access to cdev->chip.dev in that path dereferences a freed usb_device. On top of the refcounting issue, the current card_free implementation calls usb_reset_device(cdev->chip.dev). A reset in a free callback is inappropriate: the device is going away, the call takes the device lock in a teardown context, and the reset races with the disconnect path that the callback is already cleaning up after. Take a reference on the USB device in create_card() with usb_get_dev(), drop it with usb_put_dev() in the free callback, and remove the usb_reset_device() call.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31702", "url": "https://ubuntu.com/security/CVE-2026-31702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io() In f2fs_compress_write_end_io(), dec_page_count(sbi, type) can bring the F2FS_WB_CP_DATA counter to zero, unblocking f2fs_wait_on_all_pages() in f2fs_put_super() on a concurrent unmount CPU. The unmount path then proceeds to call f2fs_destroy_page_array_cache(sbi), which destroys sbi->page_array_slab via kmem_cache_destroy(), and eventually kfree(sbi). Meanwhile, the bio completion callback is still executing: when it reaches page_array_free(sbi, ...), it dereferences sbi->page_array_slab — a destroyed slab cache — to call kmem_cache_free(), causing a use-after-free. This is the same class of bug as CVE-2026-23234 (which fixed the equivalent race in f2fs_write_end_io() in data.c), but in the compressed writeback completion path that was not covered by that fix. Fix this by moving dec_page_count() to after page_array_free(), so that all sbi accesses complete before the counter decrement that can unblock unmount. For non-last folios (where atomic_dec_return on cic->pending_pages is nonzero), dec_page_count is called immediately before returning — page_array_free is not reached on this path, so there is no post-decrement sbi access. For the last folio, page_array_free runs while the F2FS_WB_CP_DATA counter is still nonzero (this folio has not yet decremented it), keeping sbi alive, and dec_page_count runs as the final operation.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31704", "url": "https://ubuntu.com/security/CVE-2026-31704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: use check_add_overflow() to prevent u16 DACL size overflow set_posix_acl_entries_dacl() and set_ntacl_dacl() accumulate ACE sizes in u16 variables. When a file has many POSIX ACL entries, the accumulated size can wrap past 65535, causing the pointer arithmetic (char *)pndace + *size to land within already-written ACEs. Subsequent writes then overwrite earlier entries, and pndacl->size gets a truncated value. Use check_add_overflow() at each accumulation point to detect the wrap before it corrupts the buffer, consistent with existing check_mul_overflow() usage elsewhere in smbacl.c.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31694", "url": "https://ubuntu.com/security/CVE-2026-31694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31714", "url": "https://ubuntu.com/security/CVE-2026-31714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid memory leak in f2fs_rename() syzbot reported a f2fs bug as below: BUG: memory leak unreferenced object 0xffff888127f70830 (size 16): comm \"syz.0.23\", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is in commit 40b2d55e0452 (\"f2fs: fix to create selinux label during whiteout initialization\"), we added a call to f2fs_setup_filename() without a matching call to f2fs_free_filename(), fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31716", "url": "https://ubuntu.com/security/CVE-2026-31716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") which checked different values in this same switch statement.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43075", "url": "https://ubuntu.com/security/CVE-2026-43075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_write_end_inline KASAN reports a use-after-free write of 4086 bytes in ocfs2_write_end_inline, called from ocfs2_write_end_nolock during a copy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF. The root cause is that ocfs2_try_to_write_inline_data trusts the on-disk id_count field to determine whether a write fits in inline data. On a corrupted filesystem, id_count can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer. Call trace (crash path): vfs_copy_file_range (fs/read_write.c:1634) do_splice_direct splice_direct_to_actor iter_file_splice_write ocfs2_file_write_iter generic_perform_write ocfs2_write_end ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949) ocfs2_write_end_inline (fs/ocfs2/aops.c:1915) memcpy_from_folio <-- KASAN: write OOB So add id_count upper bound check in ocfs2_validate_inode_block() to alongside the existing i_size check to fix it.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43076", "url": "https://ubuntu.com/security/CVE-2026-43076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline data i_size during inode read When reading an inode from disk, ocfs2_validate_inode_block() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's i_size can exceed the actual inline data capacity (id_count). This causes ocfs2_dir_foreach_blk_id() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory. In the syzbot report: - i_size was 1099511627576 bytes (~1TB) - Actual inline data capacity (id_count) is typically <256 bytes - A garbage rec_len (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2_check_dir_entry() Fix by adding a validation check in ocfs2_validate_inode_block() to ensure inodes with inline data have i_size <= id_count. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31595", "url": "https://ubuntu.com/security/CVE-2026-31595", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23444", "url": "https://ubuntu.com/security/CVE-2026-23444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure ieee80211_tx_prepare_skb() has three error paths, but only two of them free the skb. The first error path (ieee80211_tx_prepare() returning TX_DROP) does not free it, while invoke_tx_handlers() failure and the fragmentation check both do. Add kfree_skb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211_hwsim) to avoid double-free. Document the skb ownership guarantee in the function's kdoc.", "cve_priority": "low", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23442", "url": "https://ubuntu.com/security/CVE-2026-23442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: add NULL checks for idev in SRv6 paths __in6_dev_get() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER). Add NULL checks for idev returned by __in6_dev_get() in both seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL pointer dereferences.", "cve_priority": "medium", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31594", "url": "https://ubuntu.com/security/CVE-2026-31594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31576", "url": "https://ubuntu.com/security/CVE-2026-31576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open hackrf fd \t\t\t\t\t\t.... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... \t\t\t\t\t\tsys_ioctl(fd, ...); \t\t\t\t\t\t v4l2_ioctl(); \t\t\t\t\t\t video_is_registered() // UAF!! \t\t\t\t\t\t.... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t v4l2_release() // UAF!! \t\t\t\t\t\t hackrf_video_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver's release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven't been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43058", "url": "https://ubuntu.com/security/CVE-2026-43058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix pass-by-value structs causing MSAN warnings vidtv_ts_null_write_into() and vidtv_ts_pcr_write_into() take their argument structs by value, causing MSAN to report uninit-value warnings. While only vidtv_ts_null_write_into() has triggered a report so far, both functions share the same issue. Fix by passing both structs by const pointer instead, avoiding the stack copy of the struct along with its MSAN shadow and origin metadata. The functions do not modify the structs, which is enforced by the const qualifier.", "cve_priority": "medium", "cve_public_date": "2026-05-02 07:16:00 UTC" }, { "cve": "CVE-2026-31577", "url": "https://ubuntu.com/security/CVE-2026-31577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map The DAT inode's btree node cache (i_assoc_inode) is initialized lazily during btree operations. However, nilfs_mdt_save_to_shadow_map() assumes i_assoc_inode is already initialized when copying dirty pages to the shadow map during GC. If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before any btree operation has occurred on the DAT inode, i_assoc_inode is NULL leading to a general protection fault. Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always initialized before any GC operation can use it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31578", "url": "https://ubuntu.com/security/CVE-2026-31578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` \t\tCPU0\t\t\t\t\t\tCPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); \t\t\t\t\t\tfd = sys_open(\"/path/to/dev\"); // open as102 fd \t\t\t\t\t\t.... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... \t\t\t\t\t\tsys_close(fd); \t\t\t\t\t\t as102_release() // UAF!! \t\t\t\t\t\t as102_usb_release() \t\t\t\t\t\t kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31580", "url": "https://ubuntu.com/security/CVE-2026-31580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bcache: fix cached_dev.sb_bio use-after-free and crash In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention: ``` [6888366.280350] Call Trace: [6888366.280452] blk_update_request+0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x70 [libceph] [6888366.281032] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ``` After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped. Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio. This patch hopes to wait for sb_write to complete in cached_dev_free. It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31581", "url": "https://ubuntu.com/security/CVE-2026-31581", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: fix use-after-free on disconnect In usb6fire_chip_abort(), the chip struct is allocated as the card's private data (via snd_card_new with sizeof(struct sfire_chip)). When snd_card_free_when_closed() is called and no file handles are open, the card and embedded chip are freed synchronously. The subsequent chip->card = NULL write then hits freed slab memory. Call trace: usb6fire_chip_abort sound/usb/6fire/chip.c:59 [inline] usb6fire_chip_disconnect+0x348/0x358 sound/usb/6fire/chip.c:182 usb_unbind_interface+0x1a8/0x88c drivers/usb/core/driver.c:458 ... hub_event+0x1a04/0x4518 drivers/usb/core/hub.c:5953 Fix by moving the card lifecycle out of usb6fire_chip_abort() and into usb6fire_chip_disconnect(). The card pointer is saved in a local before any teardown, snd_card_disconnect() is called first to prevent new opens, URBs are aborted while chip is still valid, and snd_card_free_when_closed() is called last so chip is never accessed after the card may be freed.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31583", "url": "https://ubuntu.com/security/CVE-2026-31583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: em28xx: fix use-after-free in em28xx_v4l2_open() em28xx_v4l2_open() reads dev->v4l2 without holding dev->lock, creating a race with em28xx_v4l2_init()'s error path and em28xx_v4l2_fini(), both of which free the em28xx_v4l2 struct and set dev->v4l2 to NULL under dev->lock. This race leads to two issues: - use-after-free in v4l2_fh_init() when accessing vdev->ctrl_handler, since the video_device is embedded in the freed em28xx_v4l2 struct. - NULL pointer dereference in em28xx_resolution_set() when accessing v4l2->norm, since dev->v4l2 has been set to NULL. Fix this by moving the mutex_lock() before the dev->v4l2 read and adding a NULL check for dev->v4l2 under the lock.", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31584", "url": "https://ubuntu.com/security/CVE-2026-31584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: fix use-after-free in encoder release path The fops_vcodec_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->encode_work. This creates a race window where the workqueue handler (mtk_venc_worker) may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release path) CPU 1 (workqueue) --------------------- ------------------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // waits for m2m job \"done\" mtk_venc_worker() v4l2_m2m_job_finish() // m2m job \"done\" // BUT worker still running! // post-job_finish access: other ctx dereferences // UAF if ctx already freed // returns (job \"done\") kfree(ctx) // ctx freed Root cause: The v4l2_m2m_ctx_release() only waits for the m2m job lifecycle (via TRANS_RUNNING flag), not the workqueue lifecycle. After v4l2_m2m_job_finish() is called, the m2m framework considers the job complete and v4l2_m2m_ctx_release() returns, but the worker function continues executing and may still access ctx. The work is queued during encode operations via: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) The worker function accesses ctx->m2m_ctx, ctx->dev, and other ctx fields even after calling v4l2_m2m_job_finish(). This vulnerability was confirmed with KASAN by running an instrumented test module that widens the post-job_finish race window. KASAN detected: BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12 Workqueue: mtk_vcodec_enc_wq mtk_venc_worker Allocated by task 47: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 Freed by task 47: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 Fix this by calling cancel_work_sync(&ctx->encode_work) before kfree(ctx). This ensures the workqueue handler is both cancelled (if pending) and synchronized (waits for any running handler to complete) before the context is freed. Placement rationale: The fix is placed after v4l2_ctrl_handler_free() and before list_del_init(&ctx->list). At this point, all m2m operations are done (v4l2_m2m_ctx_release() has returned), and we need to ensure the workqueue is synchronized before removing ctx from the list and freeing it. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during device_run() operations.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31585", "url": "https://ubuntu.com/security/CVE-2026-31585", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds > 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb->streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32): comm \"syz.0.17\", pid 6068, jiffies 4294944486 backtrace (crc 90a0c7d4): vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288 vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83 vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524 vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31586", "url": "https://ubuntu.com/security/CVE-2026-31586", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 (\"Add linux-next specific files for 20260410\") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31686", "url": "https://ubuntu.com/security/CVE-2026-31686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/kasan: fix double free for kasan pXds kasan_free_pxd() assumes the page table is always struct page aligned. But that's not always the case for all architectures. E.g. In case of powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let's just directly pass the start of the pxd table which is passed as the 1st argument. This fixes the below double free kasan issue seen with PMEM: radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages ================================================================== BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20 Free of addr c0000003c38e0000 by task ndctl/2164 CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries Call Trace: dump_stack_lvl+0x88/0xc4 (unreliable) print_report+0x214/0x63c kasan_report_invalid_free+0xe4/0x110 check_slab_allocation+0x100/0x150 kmem_cache_free+0x128/0x6e0 kasan_remove_zero_shadow+0x9c4/0xa20 memunmap_pages+0x2b8/0x5c0 devm_action_release+0x54/0x70 release_nodes+0xc8/0x1a0 devres_release_all+0xe0/0x140 device_unbind_cleanup+0x30/0x120 device_release_driver_internal+0x3e4/0x450 unbind_store+0xfc/0x110 drv_attr_store+0x78/0xb0 sysfs_kf_write+0x114/0x140 kernfs_fop_write_iter+0x264/0x3f0 vfs_write+0x3bc/0x7d0 ksys_write+0xa4/0x190 system_call_exception+0x190/0x480 system_call_vectored_common+0x15c/0x2ec ---- interrupt: 3000 at 0x7fff93b3d3f4 NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000 REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392) MSR: 800000000280f033 CR: 48888208 XER: 00000000 <...> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4 LR [00007fff93b3d3f4] 0x7fff93b3d3f4 ---- interrupt: 3000 The buggy address belongs to the object at c0000003c38e0000 which belongs to the cache pgtable-2^9 of size 4096 The buggy address is located 0 bytes inside of 4096-byte region [c0000003c38e0000, c0000003c38e1000) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:c0000003bfd63e01 flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff) page_type: f5(slab) raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000 head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01 head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected [ 138.953636] [ T2164] Memory state around the buggy address: [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953661] [ T2164] >c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953669] [ T2164] ^ [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 138.953692] [ T2164] ================================================================== [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint", "cve_priority": "low", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31587", "url": "https://ubuntu.com/security/CVE-2026-31587", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm: move component registration to unmanaged version q6apm component registers dais dynamically from ASoC toplology, which are allocated using device managed version apis. Allocating both component and dynamic dais using managed version could lead to incorrect free ordering, dai will be freed while component still holding references to it. Fix this issue by moving component to unmanged version so that the dai pointers are only freeded after the component is removed. ================================================================== BUG: KASAN: slab-use-after-free in snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] Read of size 8 at addr ffff00084493a6e8 by task kworker/u48:0/3426 Tainted: [W]=WARN Hardware name: LENOVO 21N2ZC5PUS/21N2ZC5PUS, BIOS N42ET57W (1.31 ) 08/08/2024 Workqueue: pdr_notifier_wq pdr_notifier_work [pdr_interface] Call trace: show_stack+0x28/0x7c (C) dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Allocated by task 77: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194 __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 Freed by task 3426: kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31588", "url": "https://ubuntu.com/security/CVE-2026-31588", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use scratch field in MMIO fragment to hold small write values When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31590", "url": "https://ubuntu.com/security/CVE-2026-31590", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION Drop the WARN in sev_pin_memory() on npages overflowing an int, as the WARN is comically trivially to trigger from userspace, e.g. by doing: struct kvm_enc_region range = { .addr = 0, .size = -1ul, }; __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range); Note, the checks in sev_mem_enc_register_region() that presumably exist to verify the incoming address+size are completely worthless, as both \"addr\" and \"size\" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater than ULONG_MAX. That wart will be cleaned up in the near future. \tif (range->addr > ULONG_MAX || range->size > ULONG_MAX) \t\treturn -EINVAL; Opportunistically add a comment to explain why the code calculates the number of pages the \"hard\" way, e.g. instead of just shifting @ulen.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31596", "url": "https://ubuntu.com/security/CVE-2026-31596", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle invalid dinode in ocfs2_group_extend [BUG] kernel BUG at fs/ocfs2/resize.c:308! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c:308 Code: 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe Call Trace: ... ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c:869 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [CAUSE] ocfs2_group_extend() assumes that the global bitmap inode block returned from ocfs2_inode_lock() has already been validated and BUG_ONs when the signature is not a dinode. That assumption is too strong for crafted filesystems because the JBD2-managed buffer path can bypass structural validation and return an invalid dinode to the resize ioctl. [FIX] Validate the dinode explicitly in ocfs2_group_extend(). If the global bitmap buffer does not contain a valid dinode, report filesystem corruption with ocfs2_error() and fail the resize operation instead of crashing the kernel.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31597", "url": "https://ubuntu.com/security/CVE-2026-31597", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c: \"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\" When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free. Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31598", "url": "https://ubuntu.com/security/CVE-2026-31598", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible deadlock between unlink and dio_end_io_write ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key. Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir \t ocfs2_expand_inline_dir \t down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31599", "url": "https://ubuntu.com/security/CVE-2026-31599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_channel_pmt_match_sections syzbot reported a general protection fault in vidtv_psi_desc_assign [1]. vidtv_psi_pmt_stream_init() can return NULL on memory allocation failure, but vidtv_channel_pmt_match_sections() does not check for this. When tail is NULL, the subsequent call to vidtv_psi_desc_assign(&tail->descriptor, desc) dereferences a NULL pointer offset, causing a general protection fault. Add a NULL check after vidtv_psi_pmt_stream_init(). On failure, clean up the already-allocated stream chain and return. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:vidtv_psi_desc_assign+0x24/0x90 drivers/media/test-drivers/vidtv/vidtv_psi.c:629 Call Trace: vidtv_channel_pmt_match_sections drivers/media/test-drivers/vidtv/vidtv_channel.c:349 [inline] vidtv_channel_si_init+0x1445/0x1a50 drivers/media/test-drivers/vidtv/vidtv_channel.c:479 vidtv_mux_init+0x526/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline] vidtv_start_feed+0x33e/0x4d0 drivers/media/test-drivers/vidtv/vidtv_bridge.c:239", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31602", "url": "https://ubuntu.com/security/CVE-2026-31602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Limit PTP to a single page Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256 playback streams, but the additional pages are not used by the card correctly. The CT20K2 hardware already has multiple VMEM_PTPAL registers, but using them separately would require refactoring the entire virtual memory allocation logic. ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When aggregate memory allocations exceed this limit, ct_vm_map() tries to access beyond the allocated space and causes a page fault: BUG: unable to handle page fault for address: ffffd4ae8a10a000 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count remain unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31603", "url": "https://ubuntu.com/security/CVE-2026-31603", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: sm750fb: fix division by zero in ps_to_hz() ps_to_hz() is called from hw_sm750_crtc_set_mode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUT_VSCREENINFO causes a division by zero. Fix by rejecting zero pixclock in lynxfb_ops_check_var(), consistent with other framebuffer drivers.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31604", "url": "https://ubuntu.com/security/CVE-2026-31604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix device leak on probe failure Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. This driver takes a reference to the USB device during probe but does not to release it on all probe errors (e.g. when descriptor parsing fails). Drop the redundant device reference to fix the leak, reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of further memory leaks.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31605", "url": "https://ubuntu.com/security/CVE-2026-31605", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31611", "url": "https://ubuntu.com/security/CVE-2026-31611", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require 3 sub-authorities before reading sub_auth[2] parse_dacl() compares each ACE SID against sid_unix_NFS_mode and on match reads sid.sub_auth[2] as the file mode. If sid_unix_NFS_mode is the prefix S-1-5-88-3 with num_subauth = 2 then compare_sids() compares only min(num_subauth, 2) sub-authorities so a client SID with num_subauth = 2 and sub_auth = {88, 3} will match. If num_subauth = 2 and the ACE is placed at the very end of the security descriptor, sub_auth[2] will be 4 bytes past end_of_acl. The out-of-band bytes will then be masked to the low 9 bits and applied as the file's POSIX mode, probably not something that is good to have happen. Fix this up by forcing the SID to actually carry a third sub-authority before reading it at all.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31612", "url": "https://ubuntu.com/security/CVE-2026-31612", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate EaNameLength in smb2_get_ea() smb2_get_ea() reads ea_req->EaNameLength from the client request and passes it directly to strncmp() as the comparison length without verifying that the length of the name really is the size of the input buffer received. Fix this up by properly checking the size of the name based on the value received and the overall size of the request, to prevent a later strncmp() call to use the length as a \"trusted\" size of the buffer. Without this check, uninitialized heap values might be slowly leaked to the client.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31615", "url": "https://ubuntu.com/security/CVE-2026-31615", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: renesas_usb3: validate endpoint index in standard request handlers The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math. This is just like what was done in commit ee0d382feb44 (\"usb: gadget: aspeed_udc: validate endpoint index for ast udc\") for the aspeed driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31616", "url": "https://ubuntu.com/security/CVE-2026-31616", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete() A broken/bored/mean USB host can overflow the skb_shared_info->frags[] array on a Linux gadget exposing a Phonet function by sending an unbounded sequence of full-page OUT transfers. pn_rx_complete() finalizes the skb only when req->actual < req->length, where req->length is set to PAGE_SIZE by the gadget. If the host always sends exactly PAGE_SIZE bytes per transfer, fp->rx.skb will never be reset and each completion will add another fragment via skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17), subsequent frag stores overwrite memory adjacent to the shinfo on the heap. Drop the skb and account a length error when the frag limit is reached, matching the fix applied in t7xx by commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\").", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31617", "url": "https://ubuntu.com/security/CVE-2026-31617", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb() The block_len read from the host-supplied NTB header is checked against ntb_max but has no lower bound. When block_len is smaller than opts->ndp_size, the bounds check of: \tndp_index > (block_len - opts->ndp_size) will underflow producing a huge unsigned value that ndp_index can never exceed, defeating the check entirely. The same underflow occurs in the datagram index checks against block_len - opts->dpe_size. With those checks neutered, a malicious USB host can choose ndp_index and datagram offsets that point past the actual transfer, and the skb_put_data() copies adjacent kernel memory into the network skb. Fix this by rejecting block lengths that cannot hold at least the NTB header plus one NDP. This will make block_len - opts->ndp_size and block_len - opts->dpe_size both well-defined. Commit 8d2b1a1ec9f5 (\"CDC-NCM: avoid overflow in sanity checking\") fixed a related class of issues on the host side of NCM.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31618", "url": "https://ubuntu.com/security/CVE-2026-31618", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 (\"fbdev: fb_pm2fb: Avoid potential divide by zero error\"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31619", "url": "https://ubuntu.com/security/CVE-2026-31619", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: fireworks: bound device-supplied status before string array lookup The status field in an EFW response is a 32-bit value supplied by the firewire device. efr_status_names[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value. Even worse, the status could return EFR_STATUS_INCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings. Fix this up by properly bounding the index against the array size and printing \"unknown\" if it's not recognized.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43072", "url": "https://ubuntu.com/security/CVE-2026-43072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: platform_get_irq_byname() returns an int platform_get_irq_byname() will return a negative value if an error happens, so it should be checked and not just passed directly into devm_request_threaded_irq() hoping all will be ok.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31622", "url": "https://ubuntu.com/security/CVE-2026-31622", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\"NFC: nci: Bounds check struct nfc_target arrays\") fixed similar missing checks against the same field on the NCI path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31623", "url": "https://ubuntu.com/security/CVE-2026-31623", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete() A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d (\"net: wwan: t7xx: fix potential skb->frags overflow in RX path\") did for the t7xx driver.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31624", "url": "https://ubuntu.com/security/CVE-2026-31624", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_event\") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31625", "url": "https://ubuntu.com/security/CVE-2026-31625", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: alps: fix NULL pointer dereference in alps_raw_event() Commit ecfa6f34492c (\"HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them\") attempted to fix up the HID drivers that had missed the previous fix that was done in 2ff5baa9b527 (\"HID: appleir: Fix potential NULL dereference at raw event handle\"), but the alps driver was missed. Fix this up by properly checking in the hid-alps driver that it had been claimed correctly before attempting to process the raw event.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31626", "url": "https://ubuntu.com/security/CVE-2026-31626", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify() Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using uninitialized data. Smatch warns that only 6 bytes are copied to this 8-byte (u64) variable, leaving the last two bytes uninitialized: drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify() warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes) Initializing the variable at the start of the function fixes this warning and ensures predictable behavior.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31627", "url": "https://ubuntu.com/security/CVE-2026-31627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b (\"i2c: tegra: check msg length in SMBUS block read\") to the i2c tegra driver.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31532", "url": "https://ubuntu.com/security/CVE-2026-31532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket destructor. can_rx_unregister() takes an extra reference to the socket and only drops it from the RCU callback, so freeing uniq from sk_destruct ensures the percpu area is not released until the relevant callbacks have drained. [mkl: applied manually]", "cve_priority": "high", "cve_public_date": "2026-04-23 12:17:00 UTC" }, { "cve": "CVE-2026-31629", "url": "https://ubuntu.com/security/CVE-2026-31629", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31407", "url": "https://ubuntu.com/security/CVE-2026-31407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: add missing netlink policy validations Hyunwoo Kim reports out-of-bounds access in sctp and ctnetlink. These attributes are used by the kernel without any validation. Extend the netlink policies accordingly. Quoting the reporter: nlattr_to_sctp() assigns the user-supplied CTA_PROTOINFO_SCTP_STATE value directly to ct->proto.sctp.state without checking that it is within the valid range. [..] and: ... with exp->dir = 100, the access at ct->master->tuplehash[100] reads 5600 bytes past the start of a 320-byte nf_conn object, causing a slab-out-of-bounds read confirmed by UBSAN.", "cve_priority": "medium", "cve_public_date": "2026-04-06 08:16:00 UTC" }, { "cve": "CVE-2026-43079", "url": "https://ubuntu.com/security/CVE-2026-43079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Skip discovery table for offline dies This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at \"pmu->boxes[die] = box\" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43080", "url": "https://ubuntu.com/security/CVE-2026-43080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: Drop large packets with UDP encap syzbot reported a WARN on my patch series [1]. The actual issue is an overflow of 16-bit UDP length field, and it exists in the upstream code. My series added a debug WARN with an overflow check that exposed the issue, that's why syzbot tripped on my patches, rather than on upstream code. syzbot's repro: r0 = socket$pppl2tp(0x18, 0x1, 0x1) r1 = socket$inet6_udp(0xa, 0x2, 0x0) connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c) connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\\x00', '\\xff\\xff', @empty}}}}, 0x32) writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)=\"ee\", 0x34000}], 0x1) It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP encapsulation, and l2tp_xmit_core doesn't check for overflows when it assigns the UDP length field. The value gets trimmed to 16 bites. Add an overflow check that drops oversized packets and avoids sending packets with trimmed UDP length to the wire. syzbot's stack trace (with my patch applied): len >= 65536u WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957 WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957 Modules linked in: CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline] RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline] RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327 Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f RSP: 0018:ffffc90003d67878 EFLAGS: 00010293 RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000 RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004 R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900 R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000 FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0 Call Trace: pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x503/0x550 net/socket.c:1195 do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1 vfs_writev+0x33c/0x990 fs/read_write.c:1059 do_writev+0x154/0x2e0 fs/read_write.c:1105 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f636479c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629 RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0 [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43345", "url": "https://ubuntu.com/security/CVE-2026-43345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix event ring index not programmed for IPA v5.0+ For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to CH_C_CNTXT_1. The v5.0 register definition intended to define this field in the CH_C_CNTXT_1 fmask array but used the old identifier of ERINDEX instead of CH_ERINDEX. Without a valid event ring, GSI channels could never signal transfer completions. This caused gsi_channel_trans_quiesce() to block forever in wait_for_completion(). At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43081", "url": "https://ubuntu.com/security/CVE-2026-43081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+ Fix the field masks to match the hardware layout documented in downstream GSI (GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*). Notably this fixes a WARN I was seeing when I tried to send \"stop\" to the MPSS remoteproc while IPA was up.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31673", "url": "https://ubuntu.com/security/CVE-2026-31673", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43082", "url": "https://ubuntu.com/security/CVE-2026-43082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: txgbe: leave space for null terminators on property_entry Lists of struct property_entry are supposed to be terminated with an empty property, this driver currently seems to be allocating exactly the amount of entry used. Change the struct definition to leave an extra element for all property_entry.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31681", "url": "https://ubuntu.com/security/CVE-2026-31681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43085", "url": "https://ubuntu.com/security/CVE-2026-43085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43086", "url": "https://ubuntu.com/security/CVE-2026-43086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix NULL deref in ip_vs_add_service error path When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local variable sched is set to NULL. If ip_vs_start_estimator() subsequently fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched) with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL check (because svc->scheduler was set by the successful bind) but then dereferences the NULL sched parameter at sched->done_service, causing a kernel panic at offset 0x30 from NULL. Oops: general protection fault, [..] [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69) Call Trace: ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500) do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809) nf_setsockopt (net/netfilter/nf_sockopt.c:102) [..] Fix by simply not clearing the local sched variable after a successful bind. ip_vs_unbind_scheduler() already detects whether a scheduler is installed via svc->scheduler, and keeping sched non-NULL ensures the error path passes the correct pointer to both ip_vs_unbind_scheduler() and ip_vs_scheduler_put(). While the bug is older, the problem popups in more recent kernels (6.2), when the new error path is taken after the ip_vs_start_estimator() call.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43089", "url": "https://ubuntu.com/security/CVE-2026-43089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_mapping() struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43091", "url": "https://ubuntu.com/security/CVE-2026-43091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: Wait for RCU readers during policy netns exit xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43092", "url": "https://ubuntu.com/security/CVE-2026-43092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: validate MTU against usable frame size on bind AF_XDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk. This becomes a problem since we started to respect tailroom which is subtracted from chunk_size (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via net_device::xdp_zc_max_segs).", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43093", "url": "https://ubuntu.com/security/CVE-2026-43093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skb_shared_info stored at the end of XSK frame would be corrupted. HW typically works with 128-aligned sizes so let us provide this value as bare minimum. Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43094", "url": "https://ubuntu.com/security/CVE-2026-43094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: add missing negotiate_features op to Hyper-V ops table Commit a7075f501bd3 (\"ixgbevf: fix mailbox API compatibility by negotiating supported features\") added the .negotiate_features callback to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL on Hyper-V VMs. During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(), which unconditionally dereferences hw->mac.ops.negotiate_features(). On Hyper-V this results in a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...] Workqueue: events work_for_cpu_fn RIP: 0010:0x0 [...] Call Trace: ixgbevf_negotiate_api+0x66/0x160 [ixgbevf] ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf] ixgbevf_probe+0x20f/0x4a0 [ixgbevf] local_pci_probe+0x50/0xa0 work_for_cpu_fn+0x1a/0x30 [...] Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP gracefully.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43098", "url": "https://ubuntu.com/security/CVE-2026-43098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: s3fwrn5: allocate rx skb before consuming bytes s3fwrn82_uart_read() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already deliver a complete frame before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43099", "url": "https://ubuntu.com/security/CVE-2026-43099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: fix null-ptr-deref in icmp_build_probe() ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing this error pointer to dev_hold() will cause a kernel crash with null-ptr-deref. Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting \"No Such Interface\".", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43103", "url": "https://ubuntu.com/security/CVE-2026-43103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lapbether: handle NETDEV_PRE_TYPE_CHANGE lapbeth_data_transmit() expects the underlying device type to be ARPHRD_ETHER. Returning NOTIFY_BAD from lapbeth_device_event() makes sure bonding driver can not break this expectation.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31684", "url": "https://ubuntu.com/security/CVE-2026-31684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43074", "url": "https://ubuntu.com/security/CVE-2026-43074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: eventpoll: defer struct eventpoll free to RCU grace period In certain situations, ep_free() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43104", "url": "https://ubuntu.com/security/CVE-2026-43104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix a memory leak in hang state error path When vc4_save_hang_state() encounters an early return condition, it returns without freeing the previously allocated `kernel_state`, leaking memory. Add the missing kfree() calls by consolidating the early return paths into a single place.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43105", "url": "https://ubuntu.com/security/CVE-2026-43105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix memory leak of BO array in hang state The hang state's BO array is allocated separately with kzalloc() in vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the missing kfree() for the BO array before freeing the hang state struct.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43110", "url": "https://ubuntu.com/security/CVE-2026-43110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: validate bsscfg indices in IF events brcmf_fweh_handle_if_event() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check. Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array. [add missing wifi prefix]", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43111", "url": "https://ubuntu.com/security/CVE-2026-43111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. This allows a concurrent roccat_release() to remove and free a reader while it's still being accessed, leading to a use-after-free. Protect the readers list traversal with the readers_lock mutex.", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43112", "url": "https://ubuntu.com/security/CVE-2026-43112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., \"/\"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read. This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL. The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.", "cve_priority": "low", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43113", "url": "https://ubuntu.com/security/CVE-2026-43113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: validate packet IDs before indexing tx_frames wl1251_tx_packet_cb() uses the firmware completion ID directly to index the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it. Reject completion IDs that fall outside wl->tx_frames[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43120", "url": "https://ubuntu.com/security/CVE-2026-43120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix double free related to rereg_user_mr If IB_MR_REREG_TRANS is set during rereg_user_mr, the umem will be released and a new one will be allocated in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans fails after the new umem is allocated, it releases the umem, but does not set iwmr->region to NULL. The problem is that this failure is propagated to the user, who will then call ibv_dereg_mr (as they should). Then, the dereg_mr path will see a non-NULL umem and attempt to call ib_umem_release again. Fix this by setting iwmr->region to NULL after ib_umem_release. Fixed: 5ac388db27c4 (\"RDMA/irdma: Add support to re-register a memory region\")", "cve_priority": "high", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31429", "url": "https://ubuntu.com/security/CVE-2026-31429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skb: fix cross-cache free of KFENCE-allocated skb head SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2 value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc bucket sizes. This ensures that skb_kfree_head() can reliably use skb_end_offset to distinguish skb heads allocated from skb_small_head_cache vs. generic kmalloc caches. However, when KFENCE is enabled, kfence_ksize() returns the exact requested allocation size instead of the slab bucket size. If a caller (e.g. bpf_test_init) allocates skb head data via kzalloc() and the requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then slab_build_skb() -> ksize() returns that exact value. After subtracting skb_shared_info overhead, skb_end_offset ends up matching SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free the object to skb_small_head_cache instead of back to the original kmalloc cache, resulting in a slab cross-cache free: kmem_cache_free(skbuff_small_head): Wrong slab cache. Expected skbuff_small_head but got kmalloc-1k Fix this by always calling kfree(head) in skb_kfree_head(). This keeps the free path generic and avoids allocator-specific misclassification for KFENCE objects.", "cve_priority": "medium", "cve_public_date": "2026-04-20 10:16:00 UTC" }, { "cve": "CVE-2026-31645", "url": "https://ubuntu.com/security/CVE-2026-31645", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page pool leak in error paths lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error paths.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-23302", "url": "https://ubuntu.com/security/CVE-2026-23302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: annotate data-races around sk->sk_{data_ready,write_space} skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently. Add corresponding READ_ONCE()/WRITE_ONCE() annotations for UDP, TCP and AF_UNIX.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23330", "url": "https://ubuntu.com/security/CVE-2026-23330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: complete pending data exchange on device close In nci_close_device(), complete any pending data exchange before closing. The data exchange callback (e.g. rawsock_data_exchange_complete) holds a socket reference. NIPA occasionally hits this leak: unreferenced object 0xff1100000f435000 (size 2048): comm \"nci_dev\", pid 3954, jiffies 4295441245 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc ec2b3c5): __kmalloc_noprof+0x4db/0x730 sk_prot_alloc.isra.0+0xe4/0x1d0 sk_alloc+0x36/0x760 rawsock_create+0xd1/0x540 nfc_sock_create+0x11f/0x280 __sock_create+0x22d/0x630 __sys_socket+0x115/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0x117/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23374", "url": "https://ubuntu.com/security/CVE-2026-23374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blktrace: fix __this_cpu_read/write in preemptible context tracing_record_cmdline() internally uses __this_cpu_read() and __this_cpu_write() on the per-CPU variable trace_cmdline_save, and trace_save_cmdline() explicitly asserts preemption is disabled via lockdep_assert_preemption_disabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probe_wakeup_sched_switch() / probe_wakeup()). __blk_add_trace() was calling tracing_record_cmdline(current) early in the blk_tracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002: blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message) [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] null_blk: disk nullb1 created [ 81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] [ 81.362886] dump_stack_lvl+0x8d/0xb0 [ 81.362895] check_preemption_disabled+0xce/0xe0 [ 81.362902] tracing_record_cmdline+0x10/0x40 [ 81.362923] __blk_add_trace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30 [ 81.362959] blk_add_trace_bio+0x106/0x1e0 [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0 [ 81.362979] ? lockdep_init_map_type+0x58/0x260 [ 81.362988] submit_bio_wait+0x56/0x90 [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250 [ 81.363026] ? __pfx_submit_bio_wait_endio+0x10/0x10 [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0 [ 81.363051] blkdev_read_iter+0xc1/0x140 [ 81.363059] vfs_read+0x20b/0x330 [ 81.363083] ksys_read+0x67/0xe0 [ 81.363090] do_syscall_64+0xbf/0xf00 [ 81.363102] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(), and blk_add_trace_rq() paths as well. The purpose of tracin ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31634", "url": "https://ubuntu.com/security/CVE-2026-31634", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31638", "url": "https://ubuntu.com/security/CVE-2026-31638", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Only put the call ref if one was acquired rxrpc_input_packet_on_conn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is no reference to drop. The client-side implicit-end error path does not account for that and unconditionally calls rxrpc_put_call(). This turns a protocol error path into a kernel crash instead of rejecting the packet. Only drop the call reference if one was actually acquired. Keep the existing protocol error handling unchanged.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31639", "url": "https://ubuntu.com/security/CVE-2026-31639", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference count leak from call->key When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ After the patch, the invalidated key is removed when the code exits: $ cat /proc/keys | grep afs@54321 $", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31642", "url": "https://ubuntu.com/security/CVE-2026-31642", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31646", "url": "https://ubuntu.com/security/CVE-2026-31646", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31648", "url": "https://ubuntu.com/security/CVE-2026-31648", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: filemap: fix nr_pages calculation overflow in filemap_map_pages() When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as \"Bad page state\": \" [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount \" After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can reproduce the crash as well and captured the first warning where the issue appears: \" [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):\"stress-ng-mmaptorture-9397-0-2736200540\" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P) [ 734.469555] set_pte_range+0xd8/0x2f8 [ 734.469566] filemap_map_folio_range+0x190/0x400 [ 734.469579] filemap_map_pages+0x348/0x638 [ 734.469583] do_fault_around+0x140/0x198 ...... [ 734.469640] el0t_64_sync+0x184/0x188 \" The code that triggers the warning is: \"VM_WARN_ON_FOLIO(page_folio(page + nr_pages - 1) != folio, folio)\", which indicates that set_pte_range() tried to map beyond the large folio’s size. By adding more debug information, I found that 'nr_pages' had overflowed in filemap_map_pages(), causing set_pte_range() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->_mapcount). After above analysis, I think the possible race is as follows: CPU 0 CPU 1 filemap_map_pages() ext4_setattr() //get and lock folio with old inode->i_size next_uptodate_folio() ....... //shrink the inode->i_size i_size_write(inode, attr->ia_size); //calculate the end_pgoff with the new inode->i_size file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; end_pgoff = min(end_pgoff, file_end); ...... //nr_pages can be overflowed, cause xas.xa_index > end_pgoff end = folio_next_index(folio) - 1; nr_pages = min(end, end_pgoff) - xas.xa_index + 1; ...... //map large folio filemap_map_folio_range() ...... //truncate folios truncate_pagecache(inode, inode->i_size); To fix this issue, move the 'end_pgoff' calculation before next_uptodate_folio(), so the retrieved folio stays consistent with the file end to avoid ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31651", "url": "https://ubuntu.com/security/CVE-2026-31651", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31655", "url": "https://ubuntu.com/security/CVE-2026-31655", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31656", "url": "https://ubuntu.com/security/CVE-2026-31656", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31658", "url": "https://ubuntu.com/security/CVE-2026-31658", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31689", "url": "https://ubuntu.com/security/CVE-2026-31689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: EDAC/mc: Fix error path ordering in edac_mc_alloc() When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device's release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they're called: MCE: In-kernel MCE decoding enabled. ------------[ cut here ]------------ kobject: '(null)': is not initialized, yet kobject_put() is being called. WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full) RIP: 0010:kobject_put Call Trace: edac_mc_alloc+0xbe/0xe0 [edac_core] amd64_edac_init+0x7a4/0xff0 [amd64_edac] ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac] do_one_initcall ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch.", "cve_priority": "medium", "cve_public_date": "2026-04-27 18:16:00 UTC" }, { "cve": "CVE-2026-31430", "url": "https://ubuntu.com/security/CVE-2026-31430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: X.509: Fix out-of-bounds access when parsing extensions Leo reports an out-of-bounds access when parsing a certificate with empty Basic Constraints or Key Usage extension because the first byte of the extension is read before checking its length. Fix it. The bug can be triggered by an unprivileged user by submitting a specially crafted certificate to the kernel through the keyrings(7) API. Leo has demonstrated this with a proof-of-concept program responsibly disclosed off-list.", "cve_priority": "medium", "cve_public_date": "2026-04-20 10:16:00 UTC" }, { "cve": "CVE-2026-31660", "url": "https://ubuntu.com/security/CVE-2026-31660", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31661", "url": "https://ubuntu.com/security/CVE-2026-31661", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: Fix dma_free_coherent() size dma_alloc_consistent() may change the size to align it. The new size is saved in alloced. Change the free size to match the allocation size.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31662", "url": "https://ubuntu.com/security/CVE-2026-31662", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31664", "url": "https://ubuntu.com/security/CVE-2026-31664", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire().", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31665", "url": "https://ubuntu.com/security/CVE-2026-31665", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31667", "url": "https://ubuntu.com/security/CVE-2026-31667", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)", "cve_priority": "low", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31670", "url": "https://ubuntu.com/security/CVE-2026-31670", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a \"large\" number (i.e. 1000) to prevent abuses like this.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31671", "url": "https://ubuntu.com/security/CVE-2026-31671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three \"empty\" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31672", "url": "https://ubuntu.com/security/CVE-2026-31672", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43336", "url": "https://ubuntu.com/security/CVE-2026-43336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: chacha: Zeroize permuted_state before it leaves scope Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done. While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG. Thus, explicitly zeroize 'permuted_state' before it goes out of scope.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2025-54505", "url": "https://ubuntu.com/security/CVE-2025-54505", "cve_description": "A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.", "cve_priority": "medium", "cve_public_date": "2026-04-27 16:16:00 UTC" }, { "cve": "CVE-2026-31628", "url": "https://ubuntu.com/security/CVE-2026-31628", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2025-62626", "url": "https://ubuntu.com/security/CVE-2025-62626", "cve_description": "Improper handling of insufficient entropy in the AMD CPUs could allow a local attacker to influence the values returned by the RDSEED instruction, potentially resulting in the consumption of insufficiently random values.", "cve_priority": "medium", "cve_public_date": "2025-11-21 19:16:00 UTC" }, { "cve": "CVE-2026-31450", "url": "https://ubuntu.com/security/CVE-2026-31450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: publish jinode after initialization ext4_inode_attach_jinode() publishes ei->jinode to concurrent users. It used to set ei->jinode before jbd2_journal_init_jbd_inode(), allowing a reader to observe a non-NULL jinode with i_vfs_inode still unset. The fast commit flush path can then pass this jinode to jbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and may crash. Below is the crash I observe: ``` BUG: unable to handle page fault for address: 000000010beb47f4 PGD 110e51067 P4D 110e51067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 RIP: 0010:xas_find_marked+0x3d/0x2e0 Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02 RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246 RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003 RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10 RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec R10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000 R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88 FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: filemap_get_folios_tag+0x87/0x2a0 __filemap_fdatawait_range+0x5f/0xd0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __schedule+0x3e7/0x10c0 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? cap_safe_nice+0x37/0x70 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 filemap_fdatawait_range_keep_errors+0x12/0x40 ext4_fc_commit+0x697/0x8b0 ? ext4_file_write_iter+0x64b/0x950 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ? srso_alias_return_thunk+0x5/0xfbef5 ? vfs_write+0x356/0x480 ? srso_alias_return_thunk+0x5/0xfbef5 ? preempt_count_sub+0x5f/0x80 ext4_sync_file+0xf7/0x370 do_fsync+0x3b/0x80 ? syscall_trace_enter+0x108/0x1d0 __x64_sys_fdatasync+0x16/0x20 do_syscall_64+0x62/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... ``` Fix this by initializing the jbd2_inode first. Use smp_wmb() and WRITE_ONCE() to publish ei->jinode after initialization. Readers use READ_ONCE() to fetch the pointer.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31466", "url": "https://ubuntu.com/security/CVE-2026-31466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix folio isn't locked in softleaf_to_folio() On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: \tCPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further swapops predicates\"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang@huawei.com: update function name and comments]", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43054", "url": "https://ubuntu.com/security/CVE-2026-43054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers \"forget about timed out scmds\" and is ready for new commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() from completing, hanging configfs LUN unlink forever in D-state: INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43056", "url": "https://ubuntu.com/security/CVE-2026-43056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: fix use-after-free in add_adev() error path If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls auxiliary_device_uninit(adev). The auxiliary device has its release callback set to adev_release(), which frees the containing struct mana_adev. Since adev is embedded in struct mana_adev, the subsequent fall-through to init_fail and access to adev->id may result in a use-after-free. Fix this by saving the allocated auxiliary device id in a local variable before calling auxiliary_device_add(), and use that saved id in the cleanup path after auxiliary_device_uninit().", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43057", "url": "https://ubuntu.com/security/CVE-2026-43057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback NETIF_F_IPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO. The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly. A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31695", "url": "https://ubuntu.com/security/CVE-2026-31695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute `SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. However, unregistering a virt_wifi device in netdev_run_todo() can happen together with the device referenced by SET_NETDEV_DEV(). It can result in use-after-free during the ethtool operations performed on a virt_wifi device that is currently being unregistered. Such a net device can have the `dev.parent` field pointing to the freed memory, but ethnl_ops_begin() calls `pm_runtime_get_sync(dev->dev.parent)`. Let's remove SET_NETDEV_DEV for virt_wifi to avoid bugs like this: ================================================================== BUG: KASAN: slab-use-after-free in __pm_runtime_resume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606 Call Trace: dump_stack_lvl+0x4d/0x70 print_report+0x170/0x4f3 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kasan_report+0xda/0x110 ? __pm_runtime_resume+0xe2/0xf0 ? __pm_runtime_resume+0xe2/0xf0 __pm_runtime_resume+0xe2/0xf0 ethnl_ops_begin+0x49/0x270 ethnl_set_features+0x23c/0xab0 ? __pfx_ethnl_set_features+0x10/0x10 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xf/0xf0 ? local_clock+0x10/0x30 ? kasan_save_track+0x25/0x60 ? __kasan_kmalloc+0x7f/0x90 ? genl_family_rcv_msg_attrs_parse.isra.0+0x150/0x2c0 genl_family_rcv_msg_doit+0x1e7/0x2c0 ? __pfx_genl_family_rcv_msg_doit+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? stack_trace_save+0x8e/0xc0 genl_rcv_msg+0x411/0x660 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_ethnl_set_features+0x10/0x10 netlink_rcv_skb+0x121/0x380 ? __pfx_genl_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_down_read+0x10/0x10 genl_rcv+0x23/0x30 netlink_unicast+0x60f/0x830 ? __pfx_netlink_unicast+0x10/0x10 ? __pfx___alloc_skb+0x10/0x10 netlink_sendmsg+0x6ea/0xbc0 ? __pfx_netlink_sendmsg+0x10/0x10 ? __futex_queue+0x10b/0x1f0 ____sys_sendmsg+0x7a2/0x950 ? copy_msghdr_from_user+0x26b/0x430 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ___sys_sendmsg+0xf8/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? __pfx_futex_wait+0x10/0x10 ? fdget+0x2e4/0x4a0 __sys_sendmsg+0x11f/0x1c0 ? __pfx___sys_sendmsg+0x10/0x10 do_syscall_64+0xe2/0x570 ? exc_page_fault+0x66/0xb0 entry_SYSCALL_64_after_hwframe+0x77/0x7f This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31720", "url": "https://ubuntu.com/security/CVE-2026-31720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data = 0; memcpy(&data, req->buf, req->length); req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write. Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data. This avoids copying a host-influenced length into a fixed-size stack object.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31721", "url": "https://ubuntu.com/security/CVE-2026-31721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_hid: move list and spinlock inits from bind to alloc There was an issue when you did the following: - setup and bind an hid gadget - open /dev/hidg0 - use the resulting fd in EPOLL_CTL_ADD - unbind the UDC - bind the UDC - use the fd in EPOLL_CTL_DEL When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported within remove_wait_queue (via ep_remove_wait_queue). After some debugging I found out that the queues, which f_hid registers via poll_wait were the problem. These were initialized using init_waitqueue_head inside hidg_bind. So effectively, the bind function re-initialized the queues while there were still items in them. The solution is to move the initialization from hidg_bind to hidg_alloc to extend their lifetimes to the lifetime of the function instance. Additionally, I found many other possibly problematic init calls in the bind function, which I moved as well.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31722", "url": "https://ubuntu.com/security/CVE-2026-31722", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowed_net flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31723", "url": "https://ubuntu.com/security/CVE-2026-31723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31724", "url": "https://ubuntu.com/security/CVE-2026-31724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31725", "url": "https://ubuntu.com/security/CVE-2026-31725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Fix net_device lifecycle with device_move The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks: console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering. To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43342", "url": "https://ubuntu.com/security/CVE-2026-43342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Protect RNDIS options with mutex The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs. Use existing mutex to protect these options. This issue was identified during code inspection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43343", "url": "https://ubuntu.com/security/CVE-2026-43343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_subset: Fix unbalanced refcnt in geth_free geth_alloc() increments the reference count, but geth_free() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function. Decrement the reference count in geth_free() to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31726", "url": "https://ubuntu.com/security/CVE-2026-31726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: fix NULL pointer dereference during unbind race Commit b81ac4395bbe (\"usb: gadget: uvc: allow for application to cleanly shutdown\") introduced two stages of synchronization waits totaling 1500ms in uvc_function_unbind() to prevent several types of kernel panics. However, this timing-based approach is insufficient during power management (PM) transitions. When the PM subsystem starts freezing user space processes, the wait_event_interruptible_timeout() is aborted early, which allows the unbind thread to proceed and nullify the gadget pointer (cdev->gadget = NULL): [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind() [ 814.178583][ T3173] PM: suspend entry (deep) [ 814.192487][ T3173] Freezing user space processes [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release When the PM subsystem resumes or aborts the suspend and tasks are restarted, the V4L2 release path is executed and attempts to access the already nullified gadget pointer, triggering a kernel panic: [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake [ 814.386727][ T3173] Restarting tasks ... [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4 [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94 [ 814.404078][ T4558] Call trace: [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4 [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94 [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac [ 814.404095][ T4558] v4l2_release+0xcc/0x130 Address the race condition and NULL pointer dereference by: 1. State Synchronization (flag + mutex) Introduce a 'func_unbound' flag in struct uvc_device. This allows uvc_function_disconnect() to safely skip accessing the nullified cdev->gadget pointer. As suggested by Alan Stern, this flag is protected by a new mutex (uvc->lock) to ensure proper memory ordering and prevent instruction reordering or speculative loads. This mutex is also used to protect 'func_connected' for consistent state management. 2. Explicit Synchronization (completion) Use a completion to synchronize uvc_function_unbind() with the uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by ensuring struct uvc_device is freed after all video device resources are released.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31728", "url": "https://ubuntu.com/security/CVE-2026-31728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop A race condition between gether_disconnect() and eth_stop() leads to a NULL pointer dereference. Specifically, if eth_stop() is triggered concurrently while gether_disconnect() is tearing down the endpoints, eth_stop() attempts to access the cleared endpoint descriptor, causing the following NPE: Unable to handle kernel NULL pointer dereference Call trace: __dwc3_gadget_ep_enable+0x60/0x788 dwc3_gadget_ep_enable+0x70/0xe4 usb_ep_enable+0x60/0x15c eth_stop+0xb8/0x108 Because eth_stop() crashes while holding the dev->lock, the thread running gether_disconnect() fails to acquire the same lock and spins forever, resulting in a hardlockup: Core - Debugging Information for Hardlockup core(7) Call trace: queued_spin_lock_slowpath+0x94/0x488 _raw_spin_lock+0x64/0x6c gether_disconnect+0x19c/0x1e8 ncm_set_alt+0x68/0x1a0 composite_setup+0x6a0/0xc50 The root cause is that the clearing of dev->port_usb in gether_disconnect() is delayed until the end of the function. Move the clearing of dev->port_usb to the very beginning of gether_disconnect() while holding dev->lock. This cuts off the link immediately, ensuring eth_stop() will see dev->port_usb as NULL and safely bail out.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2025-71269", "url": "https://ubuntu.com/security/CVE-2025-71269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not free data reservation in fallback from inline due to -ENOSPC If we fail to create an inline extent due to -ENOSPC, we will attempt to go through the normal COW path, reserve an extent, create an ordered extent, etc. However we were always freeing the reserved qgroup data, which is wrong since we will use data. Fix this by freeing the reserved qgroup data in __cow_file_range_inline() only if we are not doing the fallback (ret is <= 0).", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23389", "url": "https://ubuntu.com/security/CVE-2026-23389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix memory leak in ice_set_ringparam() In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-31729", "url": "https://ubuntu.com/security/CVE-2026-31729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_notify_common() The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries). A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsi_connector_change(). Add a bounds check in ucsi_notify_common(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43324", "url": "https://ubuntu.com/security/CVE-2026-43324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), which added an emulated \"interrupts enabled\" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c (\"usb: gadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add udc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement udc_async_callbacks in dummy-hcd\") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43327", "url": "https://ubuntu.com/security/CVE-2026-43327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second (\"driver\") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31730", "url": "https://ubuntu.com/security/CVE-2026-31730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: possible double-free of cctx->remote_heap fastrpc_init_create_static_process() may free cctx->remote_heap on the err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove() frees cctx->remote_heap again if it is non-NULL, which can lead to a double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg device is subsequently removed/unbound. Clear cctx->remote_heap after freeing it in the error path to prevent the later cleanup from freeing it again. This issue was found by an in-house analysis workflow that extracts AST-based information and runs static checks, with LLM assistance for triage, and was confirmed by manual code review. No hardware testing was performed.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43332", "url": "https://ubuntu.com/security/CVE-2026-43332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone device registration error path If thermal_zone_device_register_with_trips() fails after registering a thermal zone device, it needs to wait for the tz->removal completion like thermal_zone_device_unregister(), in case user space has managed to take a reference to the thermal zone device's kobject, in which case thermal_release() may not be called by the error path itself and tz may be freed prematurely. Add the missing wait_for_completion() call to the thermal zone device registration error path.", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43328", "url": "https://ubuntu.com/security/CVE-2026-43328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().", "cve_priority": "low", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31737", "url": "https://ubuntu.com/security/CVE-2026-31737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ftgmac100: fix ring allocation unwind on open failure ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and rx_scratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function. Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31738", "url": "https://ubuntu.com/security/CVE-2026-31738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: validate ND option lengths in vxlan_na_create vxlan_na_create() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31740", "url": "https://ubuntu.com/security/CVE-2026-31740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member The counter driver can use HW channels 1 and 2, while the PWM driver can use HW channels 0, 1, 2, 3, 4, 6, 7. The dev member is assigned both by the counter driver and the PWM driver for channels 1 and 2, to their own struct device instance, overwriting the previous value. The sub-drivers race to assign their own struct device pointer to the same struct rz_mtu3_channel's dev member. The dev member of struct rz_mtu3_channel is used by the counter sub-driver for runtime PM. Depending on the probe order of the counter and PWM sub-drivers, the dev member may point to the wrong struct device instance, causing the counter sub-driver to do runtime PM actions on the wrong device. To fix this, use the parent pointer of the counter, which is assigned during probe to the correct struct device, not the struct device pointer inside the shared struct rz_mtu3_channel.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31741", "url": "https://ubuntu.com/security/CVE-2026-31741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: rz-mtu3-cnt: prevent counter from being toggled multiple times Runtime PM counter is incremented / decremented each time the sysfs enable file is written to. If user writes 0 to the sysfs enable file multiple times, runtime PM usage count underflows, generating the following message. rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow! At the same time, hardware registers end up being accessed with clocks off in rz_mtu3_terminate_counter() to disable an already disabled channel. If user writes 1 to the sysfs enable file multiple times, runtime PM usage count will be incremented each time, requiring the same number of 0 writes to get it back to 0. If user writes 0 to the sysfs enable file while PWM is in progress, PWM is stopped without counter being the owner of the underlying MTU3 channel. Check against the cached count_is_enabled value and exit if the user is trying to set the same enable value.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31747", "url": "https://ubuntu.com/security/CVE-2026-31747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me4000: Fix potential overrun of firmware buffer `me4000_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`. Note: The firmware loading was totally broken before commit ac584af59945 (\"staging: comedi: me4000: fix firmware downloading\"), but that is the most sensible target for this fix.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31748", "url": "https://ubuntu.com/security/CVE-2026-31748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: me_daq: Fix potential overrun of firmware buffer `me2600_xilinx_download()` loads the firmware that was requested by `request_firmware()`. It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable `file_length` and reads the data stream contents of length `file_length` from offset 16 onwards. Although it checks that the supplied firmware is at least 16 bytes long, it does not check that it is long enough to contain the data stream. Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return `-EINVAL`.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31749", "url": "https://ubuntu.com/security/CVE-2026-31749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: ni_atmio16d: Fix invalid clean-up after failed attach If the driver's COMEDI \"attach\" handler function (`atmio16d_attach()`) returns an error, the COMEDI core will call the driver's \"detach\" handler function (`atmio16d_detach()`) to clean up. This calls `reset_atmio16d()` unconditionally, but depending on where the error occurred in the attach handler, the device may not have been sufficiently initialized to call `reset_atmio16d()`. It uses `dev->iobase` as the I/O port base address and `dev->private` as the pointer to the COMEDI device's private data structure. `dev->iobase` may still be set to its initial value of 0, which would result in undesired writes to low I/O port addresses. `dev->private` may still be `NULL`, which would result in null pointer dereferences. Fix `atmio16d_detach()` by checking that `dev->private` is valid (non-null) before calling `reset_atmio16d()`. This implies that `dev->iobase` was set correctly since that is set up before `dev->private`.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43340", "url": "https://ubuntu.com/security/CVE-2026-43340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: Reinit dev->spinlock between attachments to low-level drivers `struct comedi_device` is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member `spinlock` containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f (\"Staging: comedi: remove RT code\")). Some COMEDI devices (those created on initialization of the COMEDI subsystem when the \"comedi.comedi_num_legacy_minors\" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing `dev->spinlock` before calling the low-level driver's `attach` function pointer if `CONFIG_LOCKDEP` is enabled.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31751", "url": "https://ubuntu.com/security/CVE-2026-31751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: dt2815: add hardware detection to prevent crash The dt2815 driver crashes when attached to I/O ports without actual hardware present. This occurs because syzkaller or users can attach the driver to arbitrary I/O addresses via COMEDI_DEVCONFIG ioctl. When no hardware exists at the specified port, inb() operations return 0xff (floating bus), but outb() operations can trigger page faults due to undefined behavior, especially under race conditions: BUG: unable to handle page fault for address: 000000007fffff90 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:dt2815_attach+0x6e0/0x1110 Add hardware detection by reading the status register before attempting any write operations. If the read returns 0xff, assume no hardware is present and fail the attach with -ENODEV. This prevents crashes from outb() operations on non-existent hardware.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31752", "url": "https://ubuntu.com/security/CVE-2026-31752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: validate ND option lengths br_nd_send() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload. Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31754", "url": "https://ubuntu.com/security/CVE-2026-31754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31755", "url": "https://ubuntu.com/security/CVE-2026-31755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix NULL pointer dereference in ep_queue When the gadget endpoint is disabled or not yet configured, the ep->desc pointer can be NULL. This leads to a NULL pointer dereference when __cdns3_gadget_ep_queue() is called, causing a kernel crash. Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the standard return code for unconfigured endpoints. This prevents potential crashes when ep_queue is called on endpoints that are not ready.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31756", "url": "https://ubuntu.com/security/CVE-2026-31756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop() dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation. However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function. Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31758", "url": "https://ubuntu.com/security/CVE-2026-31758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. in the HCD giveback path). Call usbtmc_draw_down() to allow anchored URBs to be completed.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31759", "url": "https://ubuntu.com/security/CVE-2026-31759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free. Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31761", "url": "https://ubuntu.com/security/CVE-2026-31761", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31762", "url": "https://ubuntu.com/security/CVE-2026-31762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix irq resource leak The interrupt handler is setup but only a few lines down if iio_trigger_register() fails the function returns without properly releasing the handler. Add cleanup goto to resolve resource leak. Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn: 'irq' from request_threaded_irq() not released on lines: 1124.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31763", "url": "https://ubuntu.com/security/CVE-2026-31763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Fix incorrect free_irq() variable The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown free_irq() is called with handler mpu3050. Use correct IRQ handler when calling free_irq().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31767", "url": "https://ubuntu.com/security/CVE-2026-31767", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things. This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode. Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads. (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31768", "url": "https://ubuntu.com/security/CVE-2026-31768", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ti-adc161s626: use DMA-safe memory for spi_read() Add a DMA-safe buffer and use it for spi_read() instead of a stack memory. All SPI buffers must be DMA-safe. Since we only need up to 3 bytes, we just use a u8[] instead of __be16 and __be32 and change the conversion functions appropriately.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31770", "url": "https://ubuntu.com/security/CVE-2026-31770", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (occ) Fix division by zero in occ_show_power_1() In occ_show_power_1() case 1, the accumulator is divided by update_tag without checking for zero. If no samples have been collected yet (e.g. during early boot when the sensor block is included but hasn't been updated), update_tag is zero, causing a kernel divide-by-zero crash. The 2019 fix in commit 211186cae14d (\"hwmon: (occ) Fix division by zero issue\") only addressed occ_get_powr_avg() used by occ_show_power_2() and occ_show_power_a0(). This separate code path in occ_show_power_1() was missed. Fix this by reusing the existing occ_get_powr_avg() helper, which already handles the zero-sample case and uses mul_u64_u32_div() to multiply before dividing for better precision. Move the helper above occ_show_power_1() so it is visible at the call site. [groeck: Fix alignment problems reported by checkpatch]", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31432", "url": "https://ubuntu.com/security/CVE-2026-31432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix OOB write in QUERY_INFO for compound requests When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor. The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs. This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31772", "url": "https://ubuntu.com/security/CVE-2026-31772", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43334", "url": "https://ubuntu.com/security/CVE-2026-43334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: force responder MITM requirements before building the pairing response smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM. tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces. When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31773", "url": "https://ubuntu.com/security/CVE-2026-31773", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31776", "url": "https://ubuntu.com/security/CVE-2026-31776", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix missing SPDIFI1 index handling SPDIF1 DAIO type isn't properly handled in daio_device_index() for hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds array access. Follow the hw20k1 pattern and return the proper index for this type, too.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31778", "url": "https://ubuntu.com/security/CVE-2026-31778", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d (\"ALSA: snd_usb_caiaq: give better shortname\") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31779", "url": "https://ubuntu.com/security/CVE-2026-31779", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler() The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31780", "url": "https://ubuntu.com/security/CVE-2026-31780", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte heap buffer overflow. Widen valuesize from u8 to u32 to accommodate the full range.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31781", "url": "https://ubuntu.com/security/CVE-2026-31781", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43007", "url": "https://ubuntu.com/security/CVE-2026-43007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Handle DBC deactivation if the owner went away When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles this by calling decode_deactivate() to release the resources allocated for that DBC. Since that handling is done in the qaic_manage_ioctl() context, if the user goes away before receiving and handling the deactivation, the host will be out-of-sync with the DBCs available for use, and the DBC resources will not be freed unless the device is removed. If another user loads and requests to activate a network, then the device assigns the same DBC to that network, QAIC will \"indefinitely\" wait for dbc->in_use = false, leading the user process to hang. As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions that are received after the user has gone away.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43333", "url": "https://ubuntu.com/security/CVE-2026-43333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: reject direct access to nullable PTR_TO_BUF pointers check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31415", "url": "https://ubuntu.com/security/CVE-2026-31415", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid overflows in ip6_datagram_send_ctl() Yiming Qian reported : I believe I found a locally triggerable kernel bug in the IPv6 sendmsg ancillary-data path that can panic the kernel via `skb_under_panic()` (local DoS). The core issue is a mismatch between: - a 16-bit length accumulator (`struct ipv6_txoptions::opt_flen`, type `__u16`) and - a pointer to the *last* provided destination-options header (`opt->dst1opt`) when multiple `IPV6_DSTOPTS` control messages (cmsgs) are provided. - `include/net/ipv6.h`: - `struct ipv6_txoptions::opt_flen` is `__u16` (wrap possible). (lines 291-307, especially 298) - `net/ipv6/datagram.c:ip6_datagram_send_ctl()`: - Accepts repeated `IPV6_DSTOPTS` and accumulates into `opt_flen` without rejecting duplicates. (lines 909-933) - `net/ipv6/ip6_output.c:__ip6_append_data()`: - Uses `opt->opt_flen + opt->opt_nflen` to compute header sizes/headroom decisions. (lines 1448-1466, especially 1463-1465) - `net/ipv6/ip6_output.c:__ip6_make_skb()`: - Calls `ipv6_push_frag_opts()` if `opt->opt_flen` is non-zero. (lines 1930-1934) - `net/ipv6/exthdrs.c:ipv6_push_frag_opts()` / `ipv6_push_exthdr()`: - Push size comes from `ipv6_optlen(opt->dst1opt)` (based on the pointed-to header). (lines 1179-1185 and 1206-1211) 1. `opt_flen` is a 16-bit accumulator: - `include/net/ipv6.h:298` defines `__u16 opt_flen; /* after fragment hdr */`. 2. `ip6_datagram_send_ctl()` accepts *repeated* `IPV6_DSTOPTS` cmsgs and increments `opt_flen` each time: - In `net/ipv6/datagram.c:909-933`, for `IPV6_DSTOPTS`: - It computes `len = ((hdr->hdrlen + 1) << 3);` - It checks `CAP_NET_RAW` using `ns_capable(net->user_ns, CAP_NET_RAW)`. (line 922) - Then it does: - `opt->opt_flen += len;` (line 927) - `opt->dst1opt = hdr;` (line 928) There is no duplicate rejection here (unlike the legacy `IPV6_2292DSTOPTS` path which rejects duplicates at `net/ipv6/datagram.c:901-904`). If enough large `IPV6_DSTOPTS` cmsgs are provided, `opt_flen` wraps while `dst1opt` still points to a large (2048-byte) destination-options header. In the attached PoC (`poc.c`): - 32 cmsgs with `hdrlen=255` => `len = (255+1)*8 = 2048` - 1 cmsg with `hdrlen=0` => `len = 8` - Total increment: `32*2048 + 8 = 65544`, so `(__u16)opt_flen == 8` - The last cmsg is 2048 bytes, so `dst1opt` points to a 2048-byte header. 3. The transmit path sizes headers using the wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1463-1465`: - `headersize = sizeof(struct ipv6hdr) + (opt ? opt->opt_flen + opt->opt_nflen : 0) + ...;` With wrapped `opt_flen`, `headersize`/headroom decisions underestimate what will be pushed later. 4. When building the final skb, the actual push length comes from `dst1opt` and is not limited by wrapped `opt_flen`: - In `net/ipv6/ip6_output.c:1930-1934`: - `if (opt->opt_flen) proto = ipv6_push_frag_opts(skb, opt, proto);` - In `net/ipv6/exthdrs.c:1206-1211`, `ipv6_push_frag_opts()` pushes `dst1opt` via `ipv6_push_exthdr()`. - In `net/ipv6/exthdrs.c:1179-1184`, `ipv6_push_exthdr()` does: - `skb_push(skb, ipv6_optlen(opt));` - `memcpy(h, opt, ipv6_optlen(opt));` With insufficient headroom, `skb_push()` underflows and triggers `skb_under_panic()` -> `BUG()`: - `net/core/skbuff.c:2669-2675` (`skb_push()` calls `skb_under_panic()`) - `net/core/skbuff.c:207-214` (`skb_panic()` ends in `BUG()`) - The `IPV6_DSTOPTS` cmsg path requires `CAP_NET_RAW` in the target netns user namespace (`ns_capable(net->user_ns, CAP_NET_RAW)`). - Root (or any task with `CAP_NET_RAW`) can trigger this without user namespaces. - An unprivileged `uid=1000` user can trigger this if unprivileged user namespaces are enabled and it can create a userns+netns to obtain namespaced `CAP_NET_RAW` (the attached PoC does this). - Local denial of service: kernel BUG/panic (system crash). - ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31422", "url": "https://ubuntu.com/security/CVE-2026-31422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flow: fix NULL pointer dereference on shared blocks flow_change() calls tcf_block_q() and dereferences q->handle to derive a default baseclass. Shared blocks leave block->q NULL, causing a NULL deref when a flow filter without a fully qualified baseclass is created on a shared block. Check tcf_block_shared() before accessing block->q and return -EINVAL for shared blocks. This avoids the null-deref shown below: ======================================================================= KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:flow_change (net/sched/cls_flow.c:508) Call Trace: tc_new_tfilter (net/sched/cls_api.c:2432) rtnetlink_rcv_msg (net/core/rtnetlink.c:6980) [...] =======================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31421", "url": "https://ubuntu.com/security/CVE-2026-31421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL pointer dereference on shared blocks The old-method path in fw_classify() calls tcf_block_q() and dereferences q->handle. Shared blocks leave block->q NULL, causing a NULL deref when an empty cls_fw filter is attached to a shared block and a packet with a nonzero major skb mark is classified. Reject the configuration in fw_change() when the old method (no TCA_OPTIONS) is used on a shared block, since fw_classify()'s old-method path needs block->q which is NULL for shared blocks. The fixed null-ptr-deref calling stack: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:fw_classify (net/sched/cls_fw.c:81) Call Trace: tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860) tc_run (net/core/dev.c:4401) __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31417", "url": "https://ubuntu.com/security/CVE-2026-31417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix overflow when accumulating packets Add a check to ensure that `x25_sock.fraglen` does not overflow. The `fraglen` also needs to be resetted when purging `fragment_queue` in `x25_clear_queues()`.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43012", "url": "https://ubuntu.com/security/CVE-2026-43012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix switchdev mode rollback in case of failure If for some internal reason switchdev mode fails, we rollback to legacy mode, before this patch, rollback will unregister the uplink netdev and leave it unregistered causing the below kernel bug. To fix this, we need to avoid netdev unregister by setting the proper rollback flag 'MLX5_PRIV_FLAGS_SWITCH_LEGACY' to indicate legacy mode. devlink (431) used greatest stack depth: 11048 bytes left mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \\ \tnecvfs(0), active vports(0) mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535 mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \\ \tQUERY_HCA_CAP(0x100) op_mod(0x0) failed, \\ \tstatus bad parameter(0x3), syndrome (0x3a3846), err(-22) mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \\ \trepresentor for vport 65535 ------------[ cut here ]------------ kernel BUG at net/core/dev.c:12070! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \\ \t#9 PREEMPT(voluntary) RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0 ... Call Trace: [ 90.923094] unregister_netdevice_queue+0xad/0xf0 [ 90.923323] unregister_netdev+0x1c/0x40 [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6 [ 90.923736] esw_offloads_enable+0x8e6/0x920 [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430 [ 90.924182] ? is_mp_supported+0x57/0xb0 [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350 [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0 [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140 [ 90.925088] genl_rcv_msg+0x18b/0x290 [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10 [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10 [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10 [ 90.926206] netlink_rcv_skb+0x52/0x100 [ 90.926393] genl_rcv+0x28/0x40 [ 90.926557] netlink_unicast+0x27d/0x3d0 [ 90.926749] netlink_sendmsg+0x1f7/0x430 [ 90.926942] __sys_sendto+0x213/0x220 [ 90.927127] ? __sys_recvmsg+0x6a/0xd0 [ 90.927312] __x64_sys_sendto+0x24/0x30 [ 90.927504] do_syscall_64+0x50/0x1c0 [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 90.927929] RIP: 0033:0x7f7d0363e047", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43013", "url": "https://ubuntu.com/security/CVE-2026-43013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: lag: Check for LAG device before creating debugfs __mlx5_lag_dev_add_mdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5_ldev_add_debugfs() even when there is no valid LAG context. mlx5_ldev_add_debugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL. Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer before attempting to create the debugfs entries.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43014", "url": "https://ubuntu.com/security/CVE-2026-43014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43015", "url": "https://ubuntu.com/security/CVE-2026-43015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 (\"net: macb: fix use after free on rmmod\") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unregistered. BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60 Read of size 8 at addr ffff888104f85e00 by task modprobe/597 CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8d/0xba print_report+0x17f/0x496 kasan_report+0xd9/0x180 clk_prepare+0x5a/0x60 macb_runtime_resume+0x13d/0x410 [macb] pm_generic_runtime_resume+0x97/0xd0 __rpm_callback+0xc8/0x4d0 rpm_callback+0xf6/0x230 rpm_resume+0xeeb/0x1a70 __pm_runtime_resume+0xb4/0x170 bus_remove_device+0x2e3/0x4b0 device_del+0x5b3/0xdc0 platform_device_del+0x4e/0x280 platform_device_unregister+0x11/0x50 pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 519: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x8e/0x90 __clk_register+0x458/0x2890 clk_hw_register+0x1a/0x60 __clk_hw_register_fixed_rate+0x255/0x410 clk_register_fixed_rate+0x3c/0xa0 macb_probe+0x1d8/0x42e [macb_pci] local_pci_probe+0xd7/0x190 pci_device_probe+0x252/0x600 really_probe+0x255/0x7f0 __driver_probe_device+0x1ee/0x330 driver_probe_device+0x4c/0x1f0 __driver_attach+0x1df/0x4e0 bus_for_each_dev+0x15d/0x1f0 bus_add_driver+0x486/0x5e0 driver_register+0x23a/0x3d0 do_one_initcall+0xfd/0x4d0 do_init_module+0x18b/0x5a0 load_module+0x5663/0x7950 __do_sys_finit_module+0x101/0x180 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 597: kasan_save_stack+0x2c/0x50 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x180 __kmem_cache_free+0xbc/0x320 clk_unregister+0x6de/0x8d0 macb_remove+0x73/0xc0 [macb_pci] pci_device_remove+0xae/0x210 device_remove+0xcb/0x180 device_release_driver_internal+0x529/0x770 driver_detach+0xd4/0x1a0 bus_remove_driver+0x135/0x260 driver_unregister+0x72/0xb0 pci_unregister_driver+0x26/0x220 __do_sys_delete_module+0x32e/0x550 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31675", "url": "https://ubuntu.com/security/CVE-2026-31675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_netem: fix out-of-bounds access in packet corruption In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0. Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access. Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43016", "url": "https://ubuntu.com/security/CVE-2026-43016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready(). syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0] In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock(). Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after one RCU grace period. Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops under RCU in sk_psock_verdict_data_ready(). [0]: BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013 CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7facf899c819 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 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 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 15: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31425", "url": "https://ubuntu.com/security/CVE-2026-31425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43017", "url": "https://ubuntu.com/security/CVE-2026-43017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate mesh send advertising payload length mesh_send() currently bounds MGMT_OP_MESH_SEND by total command length, but it never verifies that the bytes supplied for the flexible adv_data[] array actually match the embedded adv_data_len field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer. Keep rejecting zero-length and oversized advertising payloads, but validate adv_data_len explicitly and require the command length to exactly match the flexible array size before queueing the request.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43018", "url": "https://ubuntu.com/security/CVE-2026-43018", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt hci_conn lookup and field access must be covered by hdev lock in hci_le_remote_conn_param_req_evt, otherwise it's possible it is freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43019", "url": "https://ubuntu.com/security/CVE-2026-43019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently. Take hdev lock to prevent hci_conn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid \"tearing\" in the configuration.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43020", "url": "https://ubuntu.com/security/CVE-2026-43020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate LTK enc_size on load Load Long Term Keys stores the user-provided enc_size and later uses it to size fixed-size stack operations when replying to LE LTK requests. An enc_size larger than the 16-byte key buffer can therefore overflow the reply stack buffer. Reject oversized enc_size values while validating the management LTK record so invalid keys never reach the stored key state.", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43023", "url": "https://ubuntu.com/security/CVE-2026-43023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43024", "url": "https://ubuntu.com/security/CVE-2026-43024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject immediate NF_QUEUE verdict nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts. The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31424", "url": "https://ubuntu.com/security/CVE-2026-31424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43025", "url": "https://ubuntu.com/security/CVE-2026-43025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ignore explicit helper on new expectations Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation. This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper: BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350 Allowing to read kernel memory bytes off the expectation boundary. CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43026", "url": "https://ubuntu.com/security/CVE-2026-43026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT. The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields. Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled. Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43027", "url": "https://ubuntu.com/security/CVE-2026-43027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_helper: pass helper to expect cleanup nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expect_iter_me() never matches any expectation and all of them survive the cleanup. After unregister returns, nfnl_cthelper_del() frees the helper object immediately. Subsequent expectation dumps or packet-driven init_conntrack() calls then dereference the freed exp->helper, causing a use-after-free. Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed. BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seq_printf+0x17a/0x240 exp_seq_show+0x2e5/0x560 seq_read_iter+0x419/0x1280 proc_reg_read+0x1ac/0x270 vfs_read+0x179/0x930 ksys_read+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)", "cve_priority": "low", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43028", "url": "https://ubuntu.com/security/CVE-2026-43028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: ensure names are nul-terminated Reject names that lack a \\0 character before feeding them to functions that expect c-strings. Fixes tag is the most recent commit that needs this change.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31416", "url": "https://ubuntu.com/security/CVE-2026-31416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: account for netlink header size This is a followup to an old bug fix: NLMSG_DONE needs to account for the netlink header size, not just the attribute size. This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43329", "url": "https://ubuntu.com/security/CVE-2026-43329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: strictly check for maximum number of actions The maximum number of flowtable hardware offload actions in IPv6 is: * ethernet mangling (4 payload actions, 2 for each ethernet address) * SNAT (4 payload actions) * DNAT (4 payload actions) * Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. * Redirect (1 action) Which makes 17, while the maximum is 16. But act_ct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions. Update flow_action_entry_next() calls to check for the maximum number of supported actions. While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31680", "url": "https://ubuntu.com/security/CVE-2026-31680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.", "cve_priority": "high", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43030", "url": "https://ubuntu.com/security/CVE-2026-43030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range == BEYOND_PKT_END && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43032", "url": "https://ubuntu.com/security/CVE-2026-43032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43035", "url": "https://ubuntu.com/security/CVE-2026-43035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to zero to prevent an info-leak When building netlink messages, tc_chain_fill_node() never initializes the tcm_info field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field. The fix simply zeroes tcm_info alongside the other fields that are already initialized.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43036", "url": "https://ubuntu.com/security/CVE-2026-43036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: use skb_header_pointer() for TCPv4 GSO frag_off check Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1]. gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths. Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying. [1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43339", "url": "https://ubuntu.com/security/CVE-2026-43339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UaF in addrconf_permanent_addr() The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion. Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31423", "url": "https://ubuntu.com/security/CVE-2026-31423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: fix divide-by-zero in rtsc_min() m2sm() converts a u32 slope to a u64 scaled value. For large inputs (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores the difference of two such u64 values in a u32 variable `dsm` and uses it as a divisor. When the difference is exactly 2^32 the truncation yields zero, causing a divide-by-zero oops in the concave-curve intersection path: Oops: divide error: 0000 RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601) Call Trace: init_ed (net/sched/sch_hfsc.c:629) hfsc_enqueue (net/sched/sch_hfsc.c:1569) [...] Widen `dsm` to u64 and replace do_div() with div64_u64() so the full difference is preserved.", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-43040", "url": "https://ubuntu.com/security/CVE-2026-43040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data The fix is simple, just zeroes the padding fields.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43041", "url": "https://ubuntu.com/security/CVE-2026-43041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43043", "url": "https://ubuntu.com/security/CVE-2026-43043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43330", "url": "https://ubuntu.com/security/CVE-2026-43330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - fix overflow on long hmac keys When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The copying is performed using kmemdup, however this leads to an overflow: reading more bytes (aligned_len - keylen) from the keylen source buffer. Fix this by replacing kmemdup with kmalloc, followed by memcpy.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43044", "url": "https://ubuntu.com/security/CVE-2026-43044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - fix DMA corruption on long hmac keys When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43046", "url": "https://ubuntu.com/security/CVE-2026-43046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject root items with drop_progress and zero drop_level [BUG] When recovering relocation at mount time, merge_reloc_root() and btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against an impossible state: a non-zero drop_progress combined with a zero drop_level in a root_item, which can be triggered: ------------[ cut here ]------------ kernel BUG at fs/btrfs/relocation.c:1545! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2 RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545 Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000 Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ... RIP: 0033:0x7f969c9a8fde Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f ---[ end trace 0000000000000000 ]--- The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic metadata fuzzing tool that corrupts btrfs metadata at runtime. [CAUSE] A non-zero drop_progress.objectid means an interrupted btrfs_drop_snapshot() left a resume point on disk, and in that case drop_level must be greater than 0 because the checkpoint is only saved at internal node levels. Although this invariant is enforced when the kernel writes the root item, it is not validated when the root item is read back from disk. That allows on-disk corruption to provide an invalid state with drop_progress.objectid != 0 and drop_level == 0. When relocation recovery later processes such a root item, merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The same invalid metadata can also trigger the corresponding BUG_ON() in btrfs_drop_snapshot(). [FIX] Fix this by validating the root_item invariant in tree-checker when reading root items from disk: if drop_progress.objectid is non-zero, drop_level must also be non-zero. Reject such malformed metadata with -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot() and triggers the BUG_ON. After the fix, the same corruption is correctly rejected by tree-checker and the BUG_ON is no longer triggered.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43338", "url": "https://ubuntu.com/security/CVE-2026-43338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reserve enough transaction items for qgroup ioctls Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve. However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve. For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNT When running this, we can see in dmesg/syslog that a transaction abort happened: [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28 [436.493] ------------[ cut here ]------------ [436.494] BTRFS: Transaction aborted (error -28) [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372 [436.497] Modules linked in: btrfs loop (...) [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [436.510] Tainted: [W]=WARN [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] Code: 0f 82 ea (...) [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292 [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001 [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80 [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867 [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400 [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000 [436.526] FS: 00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000 [436.527] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0 [436.530] Call Trace: [436.530] [436.530] btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ? __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP: 0033:0x7fe5906b6217 [436.538] Code: 0d 00 f7 (...) [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217 [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100 [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff [436.544] R10: 0000000000000103 R11: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43047", "url": "https://ubuntu.com/security/CVE-2026-43047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43049", "url": "https://ubuntu.com/security/CVE-2026-43049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure Presently, if the force feedback initialisation fails when probing the Logitech G920 Driving Force Racing Wheel for Xbox One, an error number will be returned and propagated before the userspace infrastructure (sysfs and /dev/input) has been torn down. If userspace ignores the errors and continues to use its references to these dangling entities, a UAF will promptly follow. We have 2 options; continue to return the error, but ensure that all of the infrastructure is torn down accordingly or continue to treat this condition as a warning by emitting the message but returning success. It is thought that the original author's intention was to emit the warning but keep the device functional, less the force feedback feature, so let's go with that.", "cve_priority": "high", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43050", "url": "https://ubuntu.com/security/CVE-2026-43050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: lec: fix use-after-free in sock_def_readable() A race condition exists between lec_atm_close() setting priv->lecd to NULL and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(), and lec_atm_send(). When the socket is freed via RCU while another thread is still using it, a use-after-free occurs in sock_def_readable() when accessing the socket's wait queue. The root cause is that lec_atm_close() clears priv->lecd without any synchronization, while callers dereference priv->lecd without any protection against concurrent teardown. Fix this by converting priv->lecd to an RCU-protected pointer: - Mark priv->lecd as __rcu in lec.h - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach() for safe pointer assignment - Use rcu_access_pointer() for NULL checks that do not dereference the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and lecd_attach() - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(), lec_handle_bridge() and lec_atm_send() to safely access lecd - Use rcu_assign_pointer() followed by synchronize_rcu() in lec_atm_close() to ensure all readers have completed before proceeding. This is safe since lec_atm_close() is called from vcc_release() which holds lock_sock(), a sleeping lock. - Remove the manual sk_receive_queue drain from lec_atm_close() since vcc_destroy_socket() already drains it after lec_atm_close() returns. v2: Switch from spinlock + sock_hold/put approach to RCU to properly fix the race. The v1 spinlock approach had two issues pointed out by Eric Dumazet: 1. priv->lecd was still accessed directly after releasing the lock instead of using a local copy. 2. The spinlock did not prevent packets being queued after lec_atm_close() drains sk_receive_queue since timer and workqueue paths bypass netif_stop_queue(). Note: Syzbot patch testing was attempted but the test VM terminated unexpectedly with \"Connection to localhost closed by remote host\", likely due to a QEMU AHCI emulation issue unrelated to this fix. Compile testing with \"make W=1 net/atm/lec.o\" passes cleanly.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43051", "url": "https://ubuntu.com/security/CVE-2026-43051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq The wacom_intuos_bt_irq() function processes Bluetooth HID reports without sufficient bounds checking. A maliciously crafted short report can trigger an out-of-bounds read when copying data into the wacom structure. Specifically, report 0x03 requires at least 22 bytes to safely read the processed data and battery status, while report 0x04 (which falls through to 0x03) requires 32 bytes. Add explicit length checks for these report IDs and log a warning if a short report is received.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43052", "url": "https://ubuntu.com/security/CVE-2026-43052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check tdls flag in ieee80211_tdls_oper When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the station exists but not whether it is actually a TDLS station. This allows the operation to proceed for non-TDLS stations, causing unintended side effects like modifying channel context and HT protection before failing. Add a check for sta->sta.tdls early in the ENABLE_LINK case, before any side effects occur, to ensure the operation is only allowed for actual TDLS peers.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43067", "url": "https://ubuntu.com/security/CVE-2026-43067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 (\"ext4: always allocate blocks only from groups inode can use\") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2025-39930", "url": "https://ubuntu.com/security/CVE-2025-39930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai() commit 419d1918105e (\"ASoC: simple-card-utils: use __free(device_node) for device node\") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use. Don't use __free(device_node) in graph_util_parse_dai().", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2026-46244", "url": "https://ubuntu.com/security/CVE-2026-46244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: Fix IPv6 inner_thoff desync In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2. For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.", "cve_priority": "medium", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-43185", "url": "https://ubuntu.com/security/CVE-2026-43185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message. By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow. This fix replaces min_t(int, ...) with min_t(u32)", "cve_priority": "critical", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-46289", "url": "https://ubuntu.com/security/CVE-2026-46289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/scatterlist: fix length calculations in extract_kvec_to_sg Patch series \"Fix bugs in extract_iter_to_sg()\", v3. Fix bugs in the kvec and user variants of extract_iter_to_sg. This series is growing due to useful remarks made by sashiko.dev. The main bugs are: - The length for an sglist entry when extracting from a kvec can exceed the number of bytes in the page. This is obviously not intended. - When extracting a user buffer the sglist is temporarily used as a scratch buffer for extracted page pointers. If the sglist already contains some elements this scratch buffer could overlap with existing entries in the sglist. The series adds test cases to the kunit_iov_iter test that demonstrate all of these bugs. Additionally, there is a memory leak fix for the test itself. The bugs were orignally introduced into kernel v6.3 where the function lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in v6.5. Thus the actual fix is only marked for backports to v6.5+. This patch (of 5): When extracting from a kvec to a scatterlist, do not cross page boundaries. The required length was already calculated but not used as intended. Adjust the copied length if the loop runs out of sglist entries without extracting everything. While there, return immediately from extract_iter_to_sg if there are no sglist entries at all. A subsequent commit will add kunit test cases that demonstrate that the patch is necessary.", "cve_priority": "medium", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46119", "url": "https://ubuntu.com/security/CVE-2026-46119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46185", "url": "https://ubuntu.com/security/CVE-2026-46185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46115", "url": "https://ubuntu.com/security/CVE-2026-46115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: add pgmap check to biovec_phys_mergeable biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-43501", "url": "https://ubuntu.com/security/CVE-2026-43501", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: \tskb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.", "cve_priority": "critical", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-45988", "url": "https://ubuntu.com/security/CVE-2026-45988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46043", "url": "https://ubuntu.com/security/CVE-2026-46043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.", "cve_priority": "critical", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-43493", "url": "https://ubuntu.com/security/CVE-2026-43493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.", "cve_priority": "high", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43071", "url": "https://ubuntu.com/security/CVE-2026-43071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dcache: Limit the minimal number of bucket to two There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260 There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB! Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.", "cve_priority": "low", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-31685", "url": "https://ubuntu.com/security/CVE-2026-31685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-43117", "url": "https://ubuntu.com/security/CVE-2026-43117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash. Use file_inode(file)->i_sb to always get btrfs_sb.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-43114", "url": "https://ubuntu.com/security/CVE-2026-43114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry New test case fails unexpectedly when avx2 matching functions are used. The test first loads a ranomly generated pipapo set with 'ipv4 . port' key, i.e. nft -f foo. This works. Then, it reloads the set after a flush: (echo flush set t s; cat foo) | nft -f - This is expected to work, because its the same set after all and it was already loaded once. But with avx2, this fails: nft reports a clashing element. The reported clash is of following form: We successfully re-inserted a . b c . d Then we try to insert a . d avx2 finds the already existing a . d, which (due to 'flush set') is marked as invalid in the new generation. It skips the element and moves to next. Due to incorrect masking, the skip-step finds the next matching element *only considering the first field*, i.e. we return the already reinserted \"a . b\", even though the last field is different and the entry should not have been matched. No such error is reported for the generic c implementation (no avx2) or when the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback. Bisection points to 7711f4bb4b36 (\"netfilter: nft_set_pipapo: fix range overlap detection\") but that fix merely uncovers this bug. Before this commit, the wrong element is returned, but erronously reported as a full, identical duplicate. The root-cause is too early return in the avx2 match functions. When we process the last field, we should continue to process data until the entire input size has been consumed to make sure no stale bits remain in the map.", "cve_priority": "medium", "cve_public_date": "2026-05-06 10:16:00 UTC" }, { "cve": "CVE-2026-31607", "url": "https://ubuntu.com/security/CVE-2026-31607", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the *original* number_of_packets from the CMD_SUBMIT. A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region. KASAN confirmed this with kernel 7.0.0-rc5: BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69 The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40) The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input\"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets. This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size. Kelvin Mbogo's series (\"usb: usbip: fix integer overflow in usbip_recv_iso()\", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31659", "url": "https://ubuntu.com/security/CVE-2026-31659", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31649", "url": "https://ubuntu.com/security/CVE-2026-31649", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31657", "url": "https://ubuntu.com/security/CVE-2026-31657", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31637", "url": "https://ubuntu.com/security/CVE-2026-31637", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.", "cve_priority": "critical", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31669", "url": "https://ubuntu.com/security/CVE-2026-31669", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.", "cve_priority": "high", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-31668", "url": "https://ubuntu.com/security/CVE-2026-31668", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-43011", "url": "https://ubuntu.com/security/CVE-2026-43011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); }", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43037", "url": "https://ubuntu.com/security/CVE-2026-43037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb[] in ip4ip6_err() Oskar Kjos reported the following problem. ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr value. __ip_options_echo() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE). To fix this we clear skb2->cb[], as suggested by Oskar Kjos. Also add minimal IPv4 header validation (version == 4, ihl >= 5).", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-43038", "url": "https://ubuntu.com/security/CVE-2026-43038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.", "cve_priority": "critical", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-31682", "url": "https://ubuntu.com/security/CVE-2026-31682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header.", "cve_priority": "medium", "cve_public_date": "2026-04-25 09:16:00 UTC" }, { "cve": "CVE-2026-31436", "url": "https://ubuntu.com/security/CVE-2026-31436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc() At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-43384", "url": "https://ubuntu.com/security/CVE-2026-43384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-31448", "url": "https://ubuntu.com/security/CVE-2026-31448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid infinite loops caused by residual data On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously. The above causes ext4_xattr_block_set() to enter an infinite loop about \"inserted\" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1]. If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases: 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case. 2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks. [1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]", "cve_priority": "low", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-31478", "url": "https://ubuntu.com/security/CVE-2026-31478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 \"ksmbd: add support for read compound\"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-23428", "url": "https://ubuntu.com/security/CVE-2026-23428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. ksmbd_tree_conn_lookup() checks t_state == TREE_CONNECTED on the initial lookup path, but the compound reuse path bypasses this check entirely. If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(), subsequent commands dereference the freed share_conf through work->tcon->share_conf. KASAN report: [ 4.144653] ================================================================== [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70 [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44 [ 4.145772] [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY [ 4.145871] 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 [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work [ 4.145888] Call Trace: [ 4.145892] [ 4.145894] dump_stack_lvl+0x64/0x80 [ 4.145910] print_report+0xce/0x660 [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 4.145928] ? smb2_write+0xc74/0xe70 [ 4.145931] kasan_report+0xce/0x100 [ 4.145934] ? smb2_write+0xc74/0xe70 [ 4.145937] smb2_write+0xc74/0xe70 [ 4.145939] ? __pfx_smb2_write+0x10/0x10 [ 4.145942] ? _raw_spin_unlock+0xe/0x30 [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480 [ 4.145951] handle_ksmbd_work+0x40f/0x1080 [ 4.145953] process_one_work+0x5fa/0xef0 [ 4.145962] ? assign_work+0x122/0x3e0 [ 4.145964] worker_thread+0x54b/0xf70 [ 4.145967] ? __pfx_worker_thread+0x10/0x10 [ 4.145970] kthread+0x346/0x470 [ 4.145976] ? recalc_sigpending+0x19b/0x230 [ 4.145980] ? __pfx_kthread+0x10/0x10 [ 4.145984] ret_from_fork+0x4fb/0x6c0 [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10 [ 4.145995] ? __switch_to+0x36c/0xbe0 [ 4.145999] ? __pfx_kthread+0x10/0x10 [ 4.146003] ret_from_fork_asm+0x1a/0x30 [ 4.146013] [ 4.146014] [ 4.149858] Allocated by task 44: [ 4.149953] kasan_save_stack+0x33/0x60 [ 4.150061] kasan_save_track+0x14/0x30 [ 4.150169] __kasan_kmalloc+0x8f/0xa0 [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0 [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600 [ 4.150529] smb2_tree_connect+0x2e6/0x1000 [ 4.150645] handle_ksmbd_work+0x40f/0x1080 [ 4.150761] process_one_work+0x5fa/0xef0 [ 4.150873] worker_thread+0x54b/0xf70 [ 4.150978] kthread+0x346/0x470 [ 4.151071] ret_from_fork+0x4fb/0x6c0 [ 4.151176] ret_from_fork_asm+0x1a/0x30 [ 4.151286] [ 4.151332] Freed by task 44: [ 4.151418] kasan_save_stack+0x33/0x60 [ 4.151526] kasan_save_track+0x14/0x30 [ 4.151634] kasan_save_free_info+0x3b/0x60 [ 4.151751] __kasan_slab_free+0x43/0x70 [ 4.151861] kfree+0x1ca/0x430 [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190 [ 4.152088] smb2_tree_disconnect+0x1cd/0x480 [ 4.152211] handle_ksmbd_work+0x40f/0x1080 [ 4.152326] process_one_work+0x5fa/0xef0 [ 4.152438] worker_thread+0x54b/0xf70 [ 4.152545] kthread+0x346/0x470 [ 4.152638] ret_from_fork+0x4fb/0x6c0 [ 4.152743] ret_from_fork_asm+0x1a/0x30 [ 4.152853] [ 4.152900] The buggy address belongs to the object at ffff88810430c180 [ 4.152900] which belongs to the cache kmalloc-96 of size 96 [ 4.153226] The buggy address is located 20 bytes inside of [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0) [ 4.153549] [ 4.153596] The buggy address belongs to the physical page: [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c [ 4.154000] flags: 0x ---truncated---", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23450", "url": "https://ubuntu.com/security/CVE-2026-23450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1]. smc_tcp_syn_recv_sock() is called in the TCP receive path (softirq) via icsk_af_ops->syn_recv_sock on the clcsock (TCP listening socket). It reads sk_user_data to get the smc_sock pointer. However, when the SMC listen socket is being closed concurrently, smc_close_active() sets clcsock->sk_user_data to NULL under sk_callback_lock, and then the smc_sock itself can be freed via sock_put() in smc_release(). This leads to two issues: 1) NULL pointer dereference: sk_user_data is NULL when accessed. 2) Use-after-free: sk_user_data is read as non-NULL, but the smc_sock is freed before its fields (e.g., queued_smc_hs, ori_af_ops) are accessed. The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcp_get_cookie_sock() -> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path has the same race): CPU A (softirq) CPU B (process ctx) tcp_v4_rcv() TCP_NEW_SYN_RECV: sk = req->rsk_listener sock_hold(sk) /* No lock on listener */ smc_close_active(): write_lock_bh(cb_lock) sk_user_data = NULL write_unlock_bh(cb_lock) ... smc_clcsock_release() sock_put(smc->sk) x2 -> smc_sock freed! tcp_check_req() smc_tcp_syn_recv_sock(): smc = user_data(sk) -> NULL or dangling smc->queued_smc_hs -> crash! Note that the clcsock and smc_sock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smc_sock from being freed. Fix this by using RCU and refcount_inc_not_zero() to safely access smc_sock. Since smc_tcp_syn_recv_sock() is called in the TCP three-way handshake path, taking read_lock_bh on sk_callback_lock is too heavy and would not survive a SYN flood attack. Using rcu_read_lock() is much more lightweight. - Set SOCK_RCU_FREE on the SMC listen socket so that smc_sock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcu_read_lock(). - Use rcu_read_lock() to protect reading sk_user_data. - Use refcount_inc_not_zero(&smc->sk.sk_refcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely. Note: smc_hs_congested() has a similar lockless read of sk_user_data without rcu_read_lock(), but it only checks for NULL and accesses the global smc_hs_wq, never dereferencing any smc_sock field, so it is not affected. Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied. [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23455", "url": "https://ubuntu.com/security/CVE-2026-23455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). If the encoded length is 0, the decrement wraps to -1, which is then passed as a large value to the decoder, leading to an out-of-bounds read. Add a check to ensure len is positive after the decrement.", "cve_priority": "high", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43378", "url": "https://ubuntu.com/security/CVE-2026-43378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix use-after-free in smb2_open() The opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is dereferenced after rcu_read_unlock(), creating a use-after-free window.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-46243", "url": "https://ubuntu.com/security/CVE-2026-46243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.", "cve_priority": "medium", "cve_public_date": "2026-06-01 17:17:00 UTC" }, { "cve": "CVE-2026-43414", "url": "https://ubuntu.com/security/CVE-2026-43414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.", "cve_priority": "low", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43407", "url": "https://ubuntu.com/security/CVE-2026-43407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In ceph_handle_auth_reply(), the value of the payload_len field of such a message is stored in a variable of type int. A value greater than INT_MAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because ceph_decode_need() only checks that the memory access does not exceed the end address of the allocation. This patch fixes the issue by changing the data type of payload_len to u32. Additionally, the data type of result_msg_len is changed to u32, as it is also a variable holding a non-negative length. Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payload_len and result_msg_len are not greater than the overall segment length. BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262 CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr ceph_con_workfn [libceph] Call Trace: dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] ? ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ? apparmor_socket_recvmsg+0x6b/0xa0 ? __pfx_mon_dispatch+0x10/0x10 [libceph] ? __kasan_check_write+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfx_mutex_unlock+0x10/0x10 ? __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ? save_fpregs_to_fpstate+0xb0/0x230 ? raw_spin_rq_unlock+0x17/0xa0 ? finish_task_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasan_check_write+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ? __kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_try_to_wake_up+0x10/0x10 ? kasan_print_address_stack_frame+0x1f7/0x280 ? __pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 [ idryomov: replace if statements with ceph_decode_need() for payload_len and result_msg_len ]", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-43406", "url": "https://ubuntu.com/security/CVE-2026-43406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.", "cve_priority": "high", "cve_public_date": "2026-05-08 15:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-136.136 -proposed tracker (LP: #2158930)", "", " * ext4: writeback causes kernel oops when low on space (LP: #2158377)", " - ext4: get rid of ppath in get_ext_path()", "", " * mount08 from ubuntu_ltp_syscalls failed - TFAIL: mount(/proc/139835/fd/4)", " succeeded (LP: #2137199)", " - proc: proc_readfd() -> proc_fd_iterate()", " - proc: proc_readfdinfo() -> proc_fdinfo_iterate()", " - proc: add proc_splice_unmountable()", " - proc: block mounting on top of /proc//map_files/*", " - proc: block mounting on top of /proc//fd/*", " - proc: block mounting on top of /proc//fdinfo/*", "", " * Add intel-speed-select to linux-tools-$(uname -r) (LP: #2131077)", " - [Packaging] Add intel-speed-select to linux-tools", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956)", " - blk-cgroup: wait for blkcg cleanup before initializing new disk", " - fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START", " - drbd: Balance RCU calls in drbd_adm_dump_devices()", " - loop: fix partition scan race between udev and loop_reread_partitions()", " - nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()", " - blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current()", " - pstore/ram: fix resource leak when ioremap() fails", " - ACPI: x86: cmos_rtc: Clean up address space handler driver", " - ACPI: x86: cmos_rtc: Improve coordination with ACPI TAD driver", " - devres: fix missing node debug info in devm_krealloc()", " - thermal/drivers/spear: Fix error condition for reading st,thermal-flags", " - debugfs: check for NULL pointer in debugfs_create_str()", " - debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str()", " - s390/cio: convert sprintf()/snprintf() to sysfs_emit()", " - s390/cio: use generic driver_override infrastructure", " - irqchip/irq-pic32-evic: Address warning related to wrong printf()", " formatter", " - hrtimers: Update the return type of enqueue_hrtimer()", " - hrtimer: Avoid pointless reprogramming in __hrtimer_start_range_ns()", " - hrtimer: Reduce trace noise in hrtimer_start()", " - locking: Fix rwlock support in ", " - firmware: dmi: Correct an indexing error in dmi.h", " - wifi: mwifiex: Fix memory leak in mwifiex_11n_aggregate_pkt()", " - wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished", " irq_prepare_bcn_tasklet", " - bpf: Add CHECKSUM_COMPLETE to bpf test progs", " - bpf: test_run: Fix the null pointer dereference issue in", " bpf_lwt_xmit_push_encap", " - dpaa2: add independent dependencies for FSL_DPAA2_SWITCH", " - [Config] Adjust CONFIG_FSL_DPAA2_SWITCH", " - dpaa2: compile dpaa2 even CONFIG_FSL_DPAA2_ETH=n", " - s390/bpf: Zero-extend bpf prog return values and kfunc arguments", " - params: Replace __modinit with __init_or_module", " - module: Fix freeing of charp module parameters when CONFIG_SYSFS=n", " - wifi: mt76: mt7921: Reset ampdu_state state in case of failure in", " mt76_connac2_tx_check_aggr()", " - wifi: mt76: mt7615: fix use_cts_prot support", " - wifi: mt76: mt7915: fix use_cts_prot support", " - wifi: mt76: mt7996: fix FCS error flag check in RX descriptor", " - arm64: cpufeature: Make PMUVer and PerfMon unsigned", " - wifi: mt76: mt7996: fix struct mt7996_mcu_uni_event", " - wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work()", " - bpf, devmap: Remove unnecessary if check in for loop", " - bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path", " - wifi: rtw89: phy: fix uninitialized variable access in", " rtw89_phy_cfo_set_crystal_cap()", " - r8152: fix incorrect register write to USB_UPHY_XTAL", " - powerpc/crash: fix backup region offset update to elfcorehdr", " - selftests/powerpc: Re-order *FLAGS to follow lib.mk", " - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15", " - macvlan: annotate data-races around port->bc_queue_len_used", " - bpf: Fix stale offload->prog pointer after constant blinding", " - wifi: brcmfmac: Fix error pointer dereference", " - bpf: Drop task_to_inode and inet_conn_established from lsm sleepable", " hooks", " - ACPI: AGDI: fix missing newline in error message", " - arm64: kexec: Remove duplicate allocation for trans_pgd", " - net: bcmgenet: fix off-by-one in bcmgenet_put_txcb", " - net: bcmgenet: add bcmgenet_has_* helpers", " - net: bcmgenet: move DESC_INDEX flow to ring 0", " - net: bcmgenet: support reclaiming unsent Tx packets", " - net: bcmgenet: switch to use 64bit statistics", " - net: bcmgenet: fix racing timeout handler", " - netfilter: xt_socket: enable defrag after all other checks", " - netfilter: nft_fwd_netdev: check ttl/hl before forwarding", " - bpf: Fix RCU stall in bpf_fd_array_map_clear()", " - 6pack: propagage new tty types", " - net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf", " - net/rds: Optimize rds_ib_laddr_check", " - net/rds: Restrict use of RDS/IB to the initial network namespace", " - bpf: Fix OOB in pcpu_init_value", " - ppp: require CAP_NET_ADMIN in target netns for unattached ioctls", " - net: ipa: Fix programming of QTIME_TIMESTAMP_CFG", " - net: ipa: Fix decoding EV_PER_EE for IPA v5.0+", " - dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110", " - net/mlx5e: Fix features not applied during netdev registration", " - net/mlx5e: IPsec, fix ASO poll timeout with read_poll_timeout_atomic()", " - bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb", " - Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds", " MTU", " - Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error", " - Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER", " - Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp", " - net: phy: move at803x PHY driver to dedicated directory", " - net: phy: qcom: at803x: Use the correct bit to disable extended next", " page", " - sctp: fix missing encap_port propagation for GSO fragments", " - net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master", " - drm/komeda: fix integer overflow in AFBC framebuffer size check", " - drm/sun4i: backend: fix error pointer dereference", " - ASoC: sti: Return errors from regmap_field_alloc()", " - ASoC: sti: use managed regmap_field allocations", " - dm cache: fix null-deref with concurrent writes in passthrough mode", " - dm cache: fix write path cache coherency in passthrough mode", " - dm cache: fix write hang in passthrough mode", " - dm cache policy smq: fix missing locks in invalidating cache blocks", " - dm cache: fix concurrent write failure in passthrough mode", " - dm cache: support shrinking the origin device", " - dm cache: fix dirty mapping checking in passthrough mode switching", " - platform/chrome: chromeos_tbmc: Drop wakeup source on remove", " - dm cache metadata: fix memory leak on metadata abort retry", " - dm log: fix out-of-bounds write due to region_count overflow", " - drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier", " in atomic_enable()", " - drm/bridge: cadence: cdns-mhdp8546-core: Add mode_valid hook to", " drm_bridge_funcs", " - drm/bridge: cadence: cdns-mhdp8546-core: Handle HDCP state in bridge", " atomic check", " - spi: fsl-qspi: Use reinit_completion() for repeated operations", " - drm/sun4i: Fix resource leaks", " - drm/amdgpu: Add default case in DVI mode validation", " - dm init: ensure device probing has finished in dm-mod.waitfor=", " - fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build", " break", " - crypto: atmel - Use unregister_{aeads,ahashes,skciphers}", " - crypto: atmel-aes - guard unregister on error in atmel_aes_register_algs", " - padata: Remove cpu online check from cpu add and removal", " - padata: Put CPU offline callback in ONLINE section to allow failure", " - drm/amdgpu/gfx10: look at the right prop for gfx queue priority", " - spi: hisi-kunpeng: prevent infinite while() loop in hisi_spi_flush_fifo", " - drm/msm/dpu: fix mismatch between power and frequency", " - drm/msm/dsi: add the missing parameter description", " - drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0", " - drm/panel: sharp-ls043t1le01: make use of prepare_prev_first", " - drm/panel: simple: Correct G190EAN01 prepare timing", " - ALSA: core: Validate compress device numbers without dynamic minors", " - drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled", " - drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs", " - drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock", " - drm/amd/pm/ci: Fix powertune defaults for Hawaii 0x67B0", " - drm/amd/pm/ci: Clear EnabledForActivity field for memory levels", " - drm/amd/pm/ci: Fill DW8 fields from SMC", " - drm/amd/pm/smu7: Add SCLK cap for quirky Hawaii board", " - ALSA: hda/realtek: fix code style (ERROR: else should follow close brace", " '}')", " - ASoC: SOF: Intel: hda: Place check before dereference", " - drm/msm/a6xx: Fix HLSQ register dumping", " - drm/msm/shrinker: Fix can_block() logic", " - drm/msm/a6xx: Use barriers while updating HFI Q headers", " - pmdomain: ti: omap_prm: Fix a reference leak on device node", " - pmdomain: imx: scu-pd: Fix device_node reference leak during ->probe()", " - ASoC: fsl_micfil: Add access property for \"VAD Detected\"", " - ASoC: fsl_micfil: Fix event generation in hwvad_put_enable()", " - ASoC: fsl_micfil: Fix event generation in hwvad_put_init_mode()", " - ASoC: fsl_micfil: Fix event generation in micfil_put_dc_remover_state()", " - ASoC: fsl_micfil: Fix event generation in micfil_quality_set()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_arc_mode_put()", " - ASoC: fsl_xcvr: Fix event generation in fsl_xcvr_mode_put()", " - ASoC: fsl_easrc: Check the variable range in fsl_easrc_iec958_put_bits()", " - ASoC: fsl_easrc: Fix value type in fsl_easrc_iec958_get_bits()", " - ASoC: fsl_easrc: Change the type for iec958 channel status controls", " - ASoC: qcom: qdsp6: topology: check widget type before accessing data", " - crypto: qat - use swab32 macro", " - ASoC: rsnd: Fix potential out-of-bounds access of component_dais[]", " - PCI: Enable AtomicOps only if Root Port supports them", " - PCI: mediatek-gen3: Prevent leaking IRQ domains when IRQ not found", " - selftests/mm: skip migration tests if NUMA is unavailable", " - Documentation: fix a hugetlbfs reservation statement", " - selftest: memcg: skip memcg_sock test if address family not supported", " - ALSA: scarlett2: Add missing sentinel initializer field", " - ASoC: SOF: compress: return the configured codec from get_params", " - PCI: tegra194: Fix polling delay for L2 state", " - PCI: tegra194: Increase LTSSM poll time on surprise link down", " - PCI: tegra194: Disable LTSSM after transition to Detect on surprise link", " down", " - PCI: tegra194: Rename 'root_bus' to 'root_port_bus' in", " tegra_pcie_downstream_dev_to_D0()", " - PCI: tegra194: Don't force the device into the D0 state before L2", " - PCI: tegra194: Disable PERST# IRQ only in Endpoint mode", " - PCI: tegra194: Use devm_gpiod_get_optional() to parse \"nvidia,refclk-", " select\"", " - PCI: tegra194: Disable direct speed change for Endpoint mode", " - PCI: tegra194: Allow system suspend when the Endpoint link is not up", " - PCI: tegra194: Use DWC IP core version", " - PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well", " - spi: mtk-snfi: unregister ECC engine on probe failure and remove()", " callback", " - ALSA: sc6000: Use standard print API", " - ALSA: sc6000: Keep the programmed board state in card-private data", " - dm cache: fix missing return in invalidate_committed's error path", " - crypto: jitterentropy - replace long-held spinlock with mutex", " - gfs2: Call unlock_new_inode before d_instantiate", " - ktest: Avoid undef warning when WARNINGS_FILE is unset", " - ktest: Honor empty per-test option overrides", " - ktest: Run POST_KTEST hooks on failure and cancellation", " - quota: Fix race of dquot_scan_active() with quota deactivation", " - gfs2: add some missing log locking", " - gfs2: prevent NULL pointer dereference during unmount", " - efi/capsule-loader: fix incorrect sizeof in phys array reallocation", " - ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine", " - ARM: dts: mediatek: mt7623: fix efuse fallback compatible", " - memory: tegra124-emc: Fix dll_change check", " - memory: tegra30-emc: Fix dll_change check", " - arm64: dts: imx8-apalis: Fix LEDs name collision", " - arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO", " (M.2 W_DISABLE1)", " - iommufd: vfio compatibility extension check for noiommu mode", " - arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count", " - arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count", " - arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value", " - arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlight", " - soc: qcom: ocmem: make the core clock optional", " - soc: qcom: ocmem: use scoped device node handling to simplify error", " paths", " - soc: qcom: ocmem: register reasons for probe deferrals", " - soc: qcom: ocmem: return -EPROBE_DEFER is ocmem is not available", " - arm64: dts: qcom: sm8450: Fix GIC_ITS range length", " - arm64: dts: qcom: sm8550: Fix GIC_ITS range length", " - arm64: dts: qcom: sm8550: Fix xo clock supply of platform SD host", " controller", " - arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes", " - arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes", " - arm64: dts: qcom: sm7225-fairphone-fp4: Fix conflicting bias pinctrl", " - arm64: dts: qcom: sdm845-xiaomi-beryllium: Mark l1a regulator as powered", " during boot", " - arm64: dts: imx8qxp-mek: switch Type-C connector power-role to dual", " - soc/tegra: cbb: Set ERD on resume for err interrupt", " - unshare: fix nsproxy leak in ksys_unshare() on set_cred_ucounts()", " failure", " - ocfs2/dlm: validate qr_numregions in dlm_match_regions()", " - ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison", " - soc: qcom: llcc: fix v1 SB syndrome register offset", " - soc: qcom: aoss: compare against normalized cooling state", " - arm64: dts: qcom: sm8250: Add missing CPU7 3.09GHz OPP", " - ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX", " - arm64/xor: fix conflicting attributes for xor_block_template", " - ARM: dts: imx27-eukrea: replace interrupts with interrupts-extended", " - ocfs2: fix listxattr handling when the buffer is full", " - ocfs2: validate bg_bits during freefrag scan", " - ocfs2: validate group add input before caching", " - dmaengine: dw-axi-dmac: Remove unnecessary return statement from void", " function", " - soundwire: bus: demote UNATTACHED state warnings to dev_dbg()", " - dmaengine: mxs-dma: Fix missing return value from", " of_dma_controller_register()", " - soundwire: cadence: Clear message complete before signaling waiting", " thread", " - tracing: Rebuild full_name on each hist_field_name() call", " - ima: check return value of crypto_shash_final() in boot aggregate", " - HID: asus: make asus_resume adhere to linux kernel coding standards", " - HID: asus: do not abort probe when not necessary", " - mtd: physmap_of_gemini: Fix disabled pinctrl state check", " - dt-bindings: interrupt-controller: arm,gic-v3: Fix EPPI range", " - mtd: spi-nor: core: correct the op.dummy.nbytes when check read", " operations", " - mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook", " - mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook", " - mtd: spi-nor: update spi_nor_fixups::post_sfdp() documentation", " - mtd: spi-nor: swp: check SR_TB flag when getting tb_mask", " - mtd: parsers: ofpart: call of_node_put() only in ofpart_fail path", " - mtd: parsers: ofpart: call of_node_get() for dedicated subpartitions", " - mtd: rawnand: sunxi: fix sunxi_nfc_hw_ecc_read_extra_oob", " - HID: usbhid: fix deadlock in hid_post_reset()", " - bpf, arm64: Fix off-by-one in check_imm signed range check", " - bpf, sockmap: Fix af_unix iter deadlock", " - bpf, sockmap: Fix af_unix null-ptr-deref in proto update", " - bpf, sockmap: Take state lock for af_unix iter", " - bpf: Fix precedence bug in convert_bpf_ld_abs alignment check", " - bpf: Fix NULL deref in map_kptr_match_type for scalar regs", " - bpf: allow UTF-8 literals in bpf_bprintf_prepare()", " - bpf, arm32: Reject BPF-to-BPF calls and callbacks in the JIT", " - pinctrl: pinctrl-pic32: Fix resource leak", " - pinctrl: cy8c95x0: remove duplicate error message", " - pinctrl: cy8c95x0: Unify messages with help of dev_err_probe()", " - pinctrl: cy8c95x0: Avoid returning positive values to user space", " - perf branch: Avoid incrementing NULL", " - perf: tools: cs-etm: Fix print issue for Coresight debug in ETE/TRBE", " trace", " - pinctrl: abx500: Fix type of 'argument' variable", " - perf lock: Fix option value type in parse_max_stack", " - perf expr: Return -EINVAL for syntax error in expr__find_ids()", " - ipmi: ssif_bmc: fix missing check for copy_to_user() partial failure", " - ipmi: ssif_bmc: fix message desynchronization after truncated response", " - ipmi: ssif_bmc: change log level to dbg in irq callback", " - perf util: Kill die() prototype, dead for a long time", " - i3c: mipi-i3c-hci: fix IBI payload length calculation for final status", " - dev_printk: add new dev_err_probe() helpers", " - backlight: sky81452-backlight: Check return value of", " devm_gpiod_get_optional() in sky81452_bl_parse_dt()", " - platform/surface: surfacepro3_button: Drop wakeup source on remove", " - leds: lgm-sso: Remove duplicate assignments for priv->mmap", " - tty: hvc_iucv: fix off-by-one in number of supported devices", " - platform/x86: panasonic-laptop: Fix OPTD notifier registration and", " cleanup", " - mfd: mc13xxx-core: Fix memory leak in mc13xxx_add_subdevice_pdata()", " - nfs/blocklayout: Fix compilation error (`make W=1`) in", " bl_write_pagelist()", " - fs/ntfs3: terminate the cached volume label after UTF-8 conversion", " - platform/x86: dell_rbu: avoid uninit value usage in packet_size_write()", " - platform/x86: dell-wmi-sysman: bound enumeration string aggregation", " - RDMA/core: Prefer NLA_NUL_STRING", " - clk: qcom: dispcc-sm8450: use RCG2 ops for DPTX1 AUX clock source", " - scsi: sg: Make sg_sysfs_class constant", " - scsi: sg: Fix sysctl sg-big-buff register during sg_init()", " - scsi: sg: Resolve soft lockup issue when opening /dev/sgX", " - clk: qcom: dispcc-sc8280xp: remove CLK_SET_RATE_PARENT from", " byte_div_clk_src dividers", " - scsi: target: core: Fix integer overflow in UNMAP bounds check", " - dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Add missing GDSCs", " - clk: qcom: gcc-sc8180x: Use retention for USB power domains", " - clk: qcom: gcc-sc8180x: Use retention for PCIe power domains", " - clk: qcom: dispcc-sm8250: Use shared ops on the mdss vsync clk", " - clk: qcom: dispcc-sm8250: Enable parents for pixel clocks", " - clk: imx: imx6q: Fix device node reference leak in pll6_bypassed()", " - clk: imx: imx6q: Fix device node reference leak in", " of_assigned_ldb_sels()", " - clk: imx8mq: Correct the CSI PHY sels", " - clk: qoriq: avoid format string warning", " - clk: xgene: Fix mapping leak in xgene_pllclk_init()", " - dt-bindings: clock: qcom,dispcc-sc7180: Define MDSS resets", " - clk: qcom: dispcc-sc7180: Add missing MDSS resets", " - lib/hexdump: print_hex_dump_bytes() calls print_hex_dump_debug()", " - clk: visconti: pll: initialize clk_init_data to zero", " - f2fs: Use sysfs_emit_at() to simplify code", " - f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()", " - drm/i915: Extract intel_dbuf_mdclk_cdclk_ratio_update()", " - drm/i915: Loop over all active pipes in intel_mbus_dbox_update", " - drm/i915/wm: Verify the correct plane DDB entry", " - crypto: sa2ul - Fix AEAD fallback algorithm names", " - crypto: ccp - copy IV using skcipher ivsize", " - arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for", " PMIC_nINT", " - PCMCIA: Fix garbled log messages for KERN_CONT", " - arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT", " - arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT", " - macvlan: fix macvlan_get_size() not reserving space for", " IFLA_MACVLAN_BC_CUTOFF", " - net/sched: sch_cake: fix NAT destination port not being updated in", " cake_update_flowkeys", " - nexthop: fix IPv6 route referencing IPv4 nexthop", " - net/sched: taprio: fix use-after-free in advance_sched() on schedule", " switch", " - tcp: add data-race annotations around tp->data_segs_out and", " tp->total_retrans", " - tcp: annotate data-races around tp->bytes_sent", " - tcp: annotate data-races around tp->bytes_retrans", " - tcp: annotate data-races around tp->dsack_dups", " - tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)", " - tcp: annotate data-races around tp->plb_rehash", " - i40e: don't advertise IFF_SUPP_NOFCS", " - e1000e: Unroll PTP in probe error handling", " - ipv6: fix possible UAF in icmpv6_rcv()", " - sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks", " - pppoe: drop PFC frames", " - netfilter: nft_osf: restrict it to ipv4", " - netfilter: conntrack: remove sprintf usage", " - netfilter: xtables: restrict several matches to inet family", " - ipvs: fix MTU check for GSO packets in tunnel mode", " - netfilter: nfnetlink_osf: fix out-of-bounds read on option matching", " - netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check", " - arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number", " - ksmbd: destroy tree_conn_ida in ksmbd_session_destroy()", " - ksmbd: Use struct_size() to improve smb_direct_rdma_xmit()", " - ksmbd: add support for supplementary groups", " - ksmbd: destroy async_ida in ksmbd_conn_free()", " - ksmbd: scope conn->binding slowpath to bound sessions only", " - net/rds: zero per-item info buffer before handing it to visitors", " - net_sched: sch_hhf: annotate data-races in hhf_dump_stats()", " - net/sched: sch_pie: annotate data-races in pie_dump_stats()", " - net/sched: sch_fq_codel: remove data-races from fq_codel_dump_stats()", " - net/sched: sch_red: annotate data-races in red_dump_stats()", " - net/sched: sch_sfb: annotate data-races in sfb_dump_stats()", " - net: dsa: realtek: rtl8365mb: fix mode mask calculation", " - nfp: fix swapped arguments in nfp_encode_basic_qdr() calls", " - tipc: fix double-free in tipc_buf_append()", " - vhost_net: fix sleeping with preempt-disabled in vhost_net_busy_poll()", " - fs/adfs: validate nzones in adfs_validate_bblk()", " - rtc: abx80x: Disable alarm feature if no interrupt attached", " - fbdev: offb: fix PCI device reference leak on probe failure", " - mailbox: mailbox-test: free channels on probe error", " - cgroup/rdma: fix integer overflow in rdmacg_try_charge()", " - mailbox: add sanity check for channel array", " - mailbox: mailbox-test: don't free the reused channel", " - mailbox: mailbox-test: initialize struct earlier", " - mailbox: mailbox-test: make data_ready a per-instance variable", " - btrfs: fix double-decrement of bytes_may_use in", " submit_one_async_extent()", " - tracing: branch: Fix inverted check on stat tracer registration", " - nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers", " - nvme-pci: fix missed admin queue sq doorbell write", " - drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG", " - drm/amdgpu: fix spelling typos", " - drm/amdgpu/uvd3.1: Don't validate the firmware when already validated", " - drm/amdgpu/gfx6: Support harvested SI chips with disabled TCCs (v2)", " - netfilter: xt_policy: fix strict mode inbound policy matching", " - netfilter: nf_conntrack_sip: don't use simple_strtoul", " - spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ", " - drm/sysfb: ofdrm: fix PCI device reference leaks", " - cdrom, scsi: sr: propagate read-only status to block layer via", " set_disk_ro()", " - netdevsim: zero initialize struct iphdr in dummy sk_buff", " - net/sched: netem: fix probability gaps in 4-state loss model", " - net/sched: netem: fix queue limit check to include reordered packets", " - net/sched: netem: only reseed PRNG when seed is explicitly provided", " - net/sched: netem: validate slot configuration", " - net/sched: netem: fix slot delay calculation overflow", " - net/sched: netem: check for negative latency and jitter", " - net/sched: sch_choke: annotate data-races in choke_dump_stats()", " - net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()", " - vrf: Fix a potential NPD when removing a port from a VRF", " - net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()", " - net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit", " - NFC: trf7970a: Ignore antenna noise when checking for RF field", " - neighbour: add RCU protection to neigh_tables[]", " - neigh: let neigh_xmit take skb ownership", " - ALSA: usb-audio: Fix potential leak of pd at parsing UAC3 streams", " - net: mctp i2c: check length before marking flow active", " - net: phy: dp83869: fix setting CLK_O_SEL field.", " - drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings", " - drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings", " - drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings", " - drm/amdgpu/vcn: set no_user_fence for VCN v4.0.3 enc ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring", " - ASoC: codecs: ab8500: Fix casting of private data", " - netfilter: skip recording stale or retransmitted INIT", " - sctp: discard stale INIT after handshake completion", " - net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)", " - net: netconsole: move newline trimming to function", " - netconsole: propagate device name truncation in dev_name_store()", " - ALSA: hda/conexant: fix some typos", " - ALSA: hda/conexant: Renaming the codec with device ID 0x1f86 and 0x1f87", " - ALSA: hda/conexant: Fix missing error check for jack detection", " - futex: Prevent lockup in requeue-PI during signal/ timeout wakeup", " - drm/amd/display: Allow DCE link encoder without AUX registers", " - drm/amd/display: Read EDID from VBIOS embedded panel info", " - bonding: 802.3ad replace MAC_ADDRESS_EQUAL with __agg_has_partner", " - net: bonding: add broadcast_neighbor option for 802.3ad", " - bonding: add support for per-port LACP actor priority", " - bonding: print churn state via netlink", " - bonding: 3ad: implement proper RCU rules for port->aggregator", " - iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING", " - iavf: stop removing VLAN filters from PF on interface down", " - iavf: wait for PF confirmation before removing VLAN filters", " - iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler", " - ice: fix NULL pointer dereference in ice_reset_all_vfs()", " - net: tls: fix strparser anchor skb leak on offload RX setup failure", " - sfc: fix error code in efx_devlink_info_running_versions()", " - net/sched: cls_flower: revert unintended changes", " - smb: client: correctly handle ErrorContextData as a flexible array", " - net: bcmgenet: Initialize u64 stats seq counter", " - net: bcmgenet: fix leaking free_bds", " - net/sched: sch_pie: annotate more data-races in pie_dump_stats()", " - netconsole: avoid out-of-bounds access on empty string in trim_newline()", " - bonding: fix NULL pointer dereference in actor_port_prio setting", " - crypto: af_alg - Cap AEAD AD length to 0x80000000", " - i40e: Cleanup PTP pins on probe failure", " - workqueue: Fix wq->cpu_pwq leak in alloc_and_link_pwqs() WQ_UNBOUND path", " - netfilter: nf_conntrack_sip: get helper before allocating expectation", " - audit: fix incorrect inheritable capability in CAPSET records", " - netfilter: nft_ct: fix missing expect put in obj eval", " - net: atlantic: preserve PCI wake-from-D3 on shutdown when WOL enabled", " - audit: enforce AUDIT_LOCKED for AUDIT_TRIM and AUDIT_MAKE_EQUIV", " - KVM: Reject wrapped offset in kvm_reset_dirty_gfn()", " - KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer", " arithmetic", " - KVM: x86: Fix Xen hypercall tracepoint argument assignment", " - ASoC: SOF: Intel: hda-dai: remove dspless special case", " - ASoC: SOF: Intel: hda-dai: add support for dspless mode beyond HDAudio", " - smb/client: fix possible infinite loop and oob read in symlink_data()", " - drm/i915/dp: Fix VSC dynamic range signaling for RGB formats", " - ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans", " - ALSA: usb-audio: Bound MIDI endpoint descriptor scans", " - ceph: fix a buffer leak in __ceph_setxattr()", " - powerpc/warp: Fix error handling in pika_dtm_thread", " - netfs: fix error handling in netfs_extract_user_iter()", " - libceph: Fix potential out-of-bounds access in osdmap_decode()", " - libceph: Fix potential null-ptr-deref in decode_choose_args()", " - libceph: Fix potential out-of-bounds access in crush_decode()", " - libceph: handle rbtree insertion error in decode_choose_args()", " - iommu/vt-d: Disable DMAR for Intel Q35 IGFX", " - drm/i915: skip __i915_request_skip() for already signaled requests", " - drm/panfrost: Fix wait_bo ioctl leaking positive return from", " dma_resv_wait_timeout()", " - drm/gma500/oaktrail_hdmi: fix i2c adapter leak on setup", " - drm/gma500/oaktrail_lvds: fix hang on init failure", " - drm/gma500/oaktrail_lvds: fix i2c adapter leaks on init", " - eventfs: Use list_add_tail_rcu() for SRCU-protected children list", " - smb: client: Use FullSessionKey for AES-256 encryption key derivation", " - btrfs: use inode already stored in local variable at btrfs_rmdir()", " - btrfs: use btrfs inodes in btrfs_rmdir() to avoid so much usage of", " BTRFS_I()", " - mptcp: drop __mptcp_fastopen_gen_msk_ackseq()", " - mptcp: fix rx timestamp corruption on fastopen", " - mptcp: pm: prio: skip closed subflows", " - mptcp: pm: kernel: correctly retransmit ADD_ADDR ID 0", " - f2fs: fix incorrect file address mapping when inline inode is unwritten", " - f2fs: fix false alarm of lockdep on cp_global_sem lock", " - spi: sifive: Simplify clock handling with devm_clk_get_enabled()", " - spi: sifive: fix controller deregistration", " - mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker", " - netfs: Fix potential uninitialised var in netfs_extract_user_iter()", " - io_uring/kbuf: use mem_is_zero()", " - md/raid1: fix the comparing region of interval tree", " - md: wake raid456 reshape waiters before suspend", " - btrfs: pass struct btrfs_inode to clone_copy_inline_extent()", " - btrfs: fix deadlock between reflink and transaction commit when using", " flushoncommit", " - bus: fsl-mc: use generic driver_override infrastructure", " - sparc/vdso: Always reject undefined references during linking", " - sparc64: vdso: Link with -z noexecstack", " - wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work()", " - wifi: mt76: mt7921: fix 6GHz regulatory update on connection", " - bpf: Fix variable length stack write over spilled pointers", " - wifi: ath10k: fix station lookup failure during disconnect", " - bpf: fix mm lifecycle in open-coded task_vma iterator", " - bpf: switch task_vma iterator from mmap_lock to per-VMA locks", " - bpf: return VMA snapshot from task_vma iterator", " - Bluetooth: SCO: check for codecs->num_codecs == 1 before assigning to", " sco_pi(sk)->codec", " - ipv4: udp: fix typos in comments", " - ipv6: udp: fix typos in comments", " - udp: Force compute_score to always inline", " - PCI: endpoint: Align pci_epc_set_msix(), pci_epc_ops::set_msix() nr_irqs", " encoding", " - PCI: dwc: ep: Fix MSI-X Table Size configuration in", " dw_pcie_ep_set_msix()", " - PCI: dwc: Invoke post_init in dw_pcie_resume_noirq()", " - PCI: dwc: Perform cleanup in the error path of dw_pcie_resume_noirq()", " - spi: spi-nxp-fspi: remove the goto in probe", " - spi: spi-nxp-fspi: enable runtime pm for fspi", " - spi: nxp-fspi: Use reinit_completion() for repeated operations", " - drm/v3d: Handle error from drm_sched_entity_init()", " - PCI: dwc: rcar-gen4: Change EPC BAR alignment to 4K as per the", " documentation", " - drm/imagination: Switch reset_reason fields from enum to u32", " - drm/msm/dsi: fix bits_per_pclk", " - drm/msm/dsi: fix hdisplay calculation for CMD mode panel", " - PCI: qcom: Advertise Hotplug Slot Capability with no Command Completion", " support", " - drm/msm/a6xx: Fix dumping A650+ debugbus blocks", " - crypto: qat - introduce fuse array", " - crypto: qat - disable 4xxx AE cluster when lead engine is fused off", " - crypto: qat - disable 420xx AE cluster when lead engine is fused off", " - crypto: qat - fix type mismatch in RAS sysfs show functions", " - PCI: tegra194: Set LTR message request before PCIe link up in Endpoint", " mode", " - PCI: tegra194: Free up Endpoint resources during remove()", " - arm64: dts: mediatek: mt8365: Describe infracfg-nao as a pure syscon", " - arm64: dts: qcom: sm8650: Fix GIC_ITS range length", " - arm64: dts: qcom: sm8650: Fix xo clock supply of SD host controller", " - arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes", " - arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins", " - arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins", " - arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label", " - hte: tegra194: remove Kconfig dependency on Tegra194 SoC", " - [Config] Adjust CONFIG_HTE_TEGRA194", " - cxl/pci: Check memdev driver binding status in cxl_reset_done()", " - ext4: fix possible null-ptr-deref in mbt_kunit_exit()", " - pinctrl: realtek: Fix function signature for config argument", " - perf maps: Fix copy_from that can break sorted by name order", " - platform/x86: asus-wmi: adjust screenpad power/brightness handling", " - platform/x86: asus-wmi: fix screenpad brightness range", " - tty: serial: ip22zilog: Fix section mispatch warning", " - clk: qcom: gcc-x1e80100: Keep GCC USB QTB clock always ON", " - erofs: unify lcn as u64 for 32-bit platforms", " - net/sched: act_mirred: fix wrong device for mac_header_xmit check in", " tcf_blockcast_redir", " - tcp: add data-race annotations for TCP_NLA_SNDQ_SIZE", " - ice: fix ICE_AQ_LINK_SPEED_M for 200G", " - net/mlx5: Fix HCA caps leak on notifier init failure", " - pwm: atmel-tcb: Cache clock rates and mark chip as atomic", " - mailbox: mtk-cmdq: Fix CURR and END addr for task insert case", " - fsnotify: fix inode reference leak in fsnotify_recalc_mask()", " - drm/amdgpu/gmc: Fix AMDGPU_GART_PLACEMENT_LOW to not overlap with VRAM", " - ASoC: amd: acp: Add DMI quirk for Valve Steam Deck OLED", " - tcp: make probe0 timer handle expired user timeout", " - drm/amdgpu/vcn: set no_user_fence for VCN v4.0.5 enc ring", " - drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.5 ring", " - ALSA: hda: cs35l56: Fix uninitialized value in cs35l56_hda_read_acpi()", " - drm/xe/debugfs: Correct printing of register whitelist ranges", " - drm/xe/gsc: Fix BO leak on error in query_compatibility_version()", " - PCI: Initialize temporary device in new_id_store()", " - ata: libata-scsi: fix requeue of deferred ATA PASS-THROUGH commands", " - drm/loongson: Use managed KMS polling", " - ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size", " - drm/xe/dma-buf: handle empty bo and UAF races", " - btrfs: do not mark inode incompressible after inline attempt fails", " - tracing: Avoid NULL return from hist_field_name() on truncation", " - Upstream stable to v6.6.141, v6.12.91", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46117", " - RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss()", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46137", " - mptcp: pm: ADD_ADDR rtx: fix potential data-race", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46160", " - btrfs: fix missing last_unlink_trans update when removing a directory", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46314", " - drm/v3d: Reject empty multisync extension to prevent infinite loop", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46274", " - io-wq: check that the predecessor is hashed in io_wq_remove_pending()", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-31707", " - ksmbd: validate response sizes in ipc_validate_msg()", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46068", " - crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-31613", " - smb: client: fix OOB reads parsing symlink error response", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-43245", " - ntfs: ->d_compare() must not block", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45846", " - bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45845", " - net/sched: taprio: fix NULL pointer dereference in class dump", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45844", " - netfilter: arp_tables: fix IEEE1394 ARP payload parsing", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45843", " - slip: bound decode() reads against the compressed packet length", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45842", " - slip: reject VJ receive packets on instances with no rstate array", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45841", " - netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45840", " - openvswitch: cap upcall PID array size and pre-size vport replies", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-46319", " - net/sched: act_ct: Only release RCU read lock after ct_ft", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45839", " - bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()", "", " * Noble update: upstream stable patchset 2026-06-16 (LP: #2156956) //", " CVE-2026-45838", " - bpf: fix end-of-list detection in cgroup_storage_get_next_key()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619)", " - regset: use kvzalloc() for regset_get_alloc()", " - selftests/bpf: validate fake register spill/fill precision backtracking", " logic", " - exit: Sleep at TASK_IDLE when waiting for application core dump", " - media: uvcvideo: Enable VB2_DMABUF for metadata stream", " - media: i2c: ov8856: free control handler on error in", " ov8856_init_controls()", " - spi: bcm63xx: fix controller deregistration", " - spi: atmel: fix controller deregistration", " - regulator: mt6357: fix OF node reference imbalance", " - regulator: max77650: fix OF node reference imbalance", " - media: rc: streamzap: Error handling in probe", " - regulator: rk808: fix OF node reference imbalance", " - regulator: act8945a: fix OF node reference imbalance", " - regulator: bd9571mwv: fix OF node reference imbalance", " - spi: lantiq-ssc: fix controller deregistration", " - spi: qup: fix controller deregistration", " - spi: at91-usart: fix controller deregistration", " - platform/x86: hp-wmi: Ignore backlight and FnLock events", " - media: pci: zoran: fix potential memory leak in zoran_probe()", " - media: dib8000: avoid division by 0 in dib8000_set_dds()", " - media: i2c: imx412: Assert reset GPIO during probe", " - media: staging: imx: request mbus_config in csi_start", " - media: i2c: ov08d10: fix image vertical start setting", " - media: omap3isp: drop the use count of v4l2 pipeline", " - spi: dln2: fix controller deregistration", " - spi: s3c64xx: fix controller deregistration", " - spi: fsl-espi: fix controller deregistration", " - spi: omap2-mcspi: fix controller deregistration", " - spi: mtk-nor: fix controller deregistration", " - spi: sh-hspi: fix controller deregistration", " - spi: bcmbca-hsspi: fix controller deregistration", " - spi: coldfire-qspi: fix controller deregistration", " - spi: sprd: fix controller deregistration", " - spi: img-spfi: fix controller deregistration", " - spi: imx: fix runtime pm leak on probe deferral", " - spi: orion: fix runtime pm leak on unbind", " - spi: orion: fix clock imbalance on registration failure", " - spi: cadence: fix controller deregistration", " - spi: cadence: fix unclocked access on unbind", " - drm/amdkfd: Add upper bound check for num_of_nodes", " - drm/amdgpu/vce: Prevent partial address patches", " - drm/radeon: add missing revision check for CI", " - drm/amdgpu: zero-initialize GART table on allocation", " - drm/amdgpu/gfx9: drop unnecessary 64-bit fence flag check in KIQ", " - drm/amdgpu/pm: add missing revision check for CI", " - drm/amdgpu/pm: align Hawaii mclk workaround with radeon", " - ipmi:ssif: Fix a shutdown race", " - ALSA: hda: cs35l56: Propagate ASP TX source control errors", " - ALSA: misc: Use guard() for spin locks", " - ALSA: core: Serialize deferred fasync state checks", " - ALSA: seq: Notify client and port info changes", " - ALSA: seq: Fix UMP group 16 filtering", " - spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()", " - spi: zynq-qspi: fix controller deregistration", " - spi: tegra114: fix controller deregistration", " - spi: tegra20-sflash: fix controller deregistration", " - spi: uniphier: Simplify clock handling with devm_clk_get_enabled()", " - spi: uniphier: fix controller deregistration", " - mm/hugetlb_cma: round up per_node before logging it", " - mm/damon/core: disallow time-quota setting zero esz", " - mm/damon/core: implement damon_kdamond_pid()", " - mm/damon/lru_sort: detect and use fresh enabled and kdamond_pid values", " - usb: typec: tcpm: reset internal port states on soft reset AMS", " - mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values", " - mtd: spi-nor: sst: Factor out common write operation to", " `sst_nor_write_data()`", " - pwm: imx-tpm: Count the number of enabled channels in probe", " - batman-adv: tp_meter: fix tp_num leak on kmalloc failure", " - tracing/probes: Limit size of event probe to 3K", " - usb: dwc3: Move GUID programming after PHY initialization", " - vsock/virtio: fix length and offset in tap skb for split packets", " - drm/amdgpu/vcn3: Avoid overflow on msg bound check", " - drm/amdgpu/vcn4: Avoid overflow on msg bound check", " - mtd: spi-nor: sst: Fix SST write failure", " - media: nxp: imx8-isi: Reduce minimum queued buffers from 2 to 0", " - media: chips-media: wave5: fix a potential memory leak in", " wave5_vdi_init()", " - media: chips-media: wave5: add missing spinlock protection for", " send_eos_event()", " - media: chips-media: wave5: add missing spinlock protection for", " handle_dynamic_resolution_change()", " - spi: st-ssc4: fix controller deregistration", " - spi: meson-spicc: fix controller deregistration", " - spi: aspeed-smc: fix controller deregistration", " - vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to", " copy", " - spi: mxs: fix controller deregistration", " - spi: pic32: fix controller deregistration", " - spi: pl022: fix controller deregistration", " - spi: npcm-pspi: fix controller deregistration", " - spi: pic32-sqi: fix controller deregistration", " - spi: mxic: fix controller deregistration", " - spi: orion: fix controller deregistration", " - drm/amdgpu: Use SMUIO 15.0.0 offsets for TSC upper and lower count.", " - drm/amdgpu: gate VM CPU HDP flush on reset lock", " - drm/amd/display: Change dither policy for 10 bpc output back to", " dithering", " - drm/xe/bo: Fix bo leak on unaligned size validation in", " xe_bo_init_locked()", " - drm/exynos: remove bridge when component_add fails", " - drm/amdkfd: Make all TLB-flushes heavy-weight", " - btrfs: remove fs_info argument from btrfs_sysfs_add_space_info_type()", " - Upstream stable to v6.6.140, v6.12.89, v6.12.90", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46207", " - vsock/virtio: fix empty payload in tap skb for non-linear buffers", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46164", " - btrfs: fix double free in create_space_info_sub_group() error path", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46201", " - drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46211", " - drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46200", " - spi: mpc52xx: fix controller deregistration", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46241", " - spi: mpc52xx: fix use-after-free on registration failure", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46214", " - vsock/virtio: fix accept queue count leak on transport mismatch", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46234", " - vsock: fix buffer size clamping order", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46159", " - btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to", " info-leak", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46208", " - batman-adv: stop tp_meter sessions during mesh teardown", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-23171", " - bonding: fix use-after-free due to enslave fail after slave array update", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-45836", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46191", " - fbcon: Avoid OOB font access if console rotation fails", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46111", " - Bluetooth: hci_conn: fix potential UAF in create_big_sync", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-45999", " - erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46044", " - ipmi:ssif: Clean up kthread on errors", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46231", " - batman-adv: bla: put backbone reference on failed claim hash insert", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46233", " - batman-adv: bla: only purge non-released claims", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46212", " - batman-adv: bla: prevent use-after-free when deleting claims", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46238", " - batman-adv: stop caching unowned originator pointers in BAT IV", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46206", " - batman-adv: reject new tp_meter sessions during teardown", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46198", " - batman-adv: fix integer overflow on buff_pos", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46227", " - sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in", " SCTP_SENDALL", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46220", " - drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46197", " - drm/amdkfd: validate SVM ioctl nattr against buffer size", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46209", " - drm/gem: Fix inconsistent plane dimension calculation in", " drm_gem_fb_init_with_funcs()", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46230", " - drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46199", " - drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46204", " - drm/amdgpu/vcn4: Prevent OOB reads when parsing IB", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46218", " - drm/amdgpu: Add bounds checking to ib_{get,set}_value", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46229", " - drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46219", " - spi: mpc52xx: fix use-after-free on unbind", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46225", " - spi: rspi: fix controller deregistration", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46226", " - spi: fsl: fix controller deregistration", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46235", " - media: saa7164: add ioremap return checks and cleanups", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46312", " - media: videobuf2: Set vma_flags in vb2_dma_sg_mmap", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46236", " - media: rc: xbox_remote: heed DMA restrictions", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46205", " - staging: media: atomisp: Disallow all private IOCTLs", "", " * Noble update: upstream stable patchset 2026-06-12 (LP: #2156619) //", " CVE-2026-46232", " - HID: playstation: Clamp num_touch_reports", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549)", " - xen/privcmd: fix double free via VMA splitting", " - Buffer overflow in drivers/xen/sys-hypervisor.c", " - ALSA: usb-audio: Avoid false E-MU sample-rate notifications", " - ALSA: usb-audio: Fix Audio Advantage Micro II SPDIF switch", " - usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()", " - usb: chipidea: otg: not wait vbus drop if use role_switch", " - usb: chipidea: core: allow ci_irq_handler() handle both ID and VBUS", " change", " - ALSA: usb-audio: Evaluate packsize caps at the right place", " - driver core: Don't let a device probe until it's ready", " - firmware: google: framebuffer: Do not mark framebuffer as busy", " - arm64/mm: Enable batched TLB flush in unmap_hotplug_range()", " - drm/amdgpu: Use vmemdup_array_user in amdgpu_bo_create_list_entry_array", " - device property: Make modifications of fwnode \"flags\" thread safe", " - um: drivers: call kernel_strrchr() explicitly in cow_user.c", " - Revert \"ALSA: usb: Increase volume range that triggers a warning\"", " - PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete", " - lib/ts_kmp: fix integer overflow in pattern length calculation", " - media: i2c: imx219: Check return value of devm_gpiod_get_optional() in", " imx219_probe()", " - ALSA: aoa: i2sbus: fix OF node lifetime handling", " - ALSA: seq_oss: return full count for successful SEQ_FULLSIZE writes", " - mfd: stpmic1: Attempt system shutdown twice in case PMIC is confused", " - nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4", " - nvme: respect NVME_QUIRK_DISABLE_WRITE_ZEROES when wzsl is set", " - parisc: _llseek syscall is only available for 32-bit userspace", " - sched: Use u64 for bandwidth ratio calculations", " - selftests/mqueue: Fix incorrectly named file", " - selftests/landlock: Fix format warning for __u64 in net_test", " - io_uring/timeout: check unused sqe fields", " - iio: adc: ti-ads7950: use iio_push_to_buffers_with_ts_unaligned()", " - io_uring/poll: fix signed comparison in io_poll_get_ownership()", " - io_uring/poll: ensure EPOLL_ONESHOT is propagated for EPOLL_URING_WAKE", " - ALSA: core: Fix potential data race at fasync handling", " - ALSA: caiaq: Fix control_put() result and cache rollback", " - ALSA: 6fire: Fix input volume change detection", " - ALSA: pcmtest: fix reference leak on failed device registration", " - ALSA: pcmtest: Fix resource leaks in module init error paths", " - iio: adc: ad7768-1: fix one-shot mode data acquisition", " - tools/accounting: handle truncated taskstats netlink messages", " - arm64: dts: marvell: uDPU: add ethernet aliases", " - net: txgbe: fix firmware version check", " - net: ks8851: Avoid excess softirq scheduling", " - drm/arcpgu: fix device node leak", " - extract-cert: Wrap key_pass with '#ifdef USE_PKCS11_ENGINE'", " - tpm: avoid -Wunused-but-set-variable", " - LoongArch: Show CPU vulnerabilites correctly", " - power: supply: axp288_charger: Do not cancel work before initializing it", " - randomize_kstack: Maintain kstack_offset per task", " - mmc: block: use single block write in retry", " - mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration", " - arm64: dts: ti: am62-verdin: Enable pullup for eMMC data pins", " - firmware: google: framebuffer: Do not unregister platform device", " - crypto: talitos - fix SEC1 32k ahash request limitation", " - crypto: talitos - rename first/last to first_desc/last_desc", " - tpm: tpm_tis: add error logging for data transfer", " - tpm: tpm_tis: stop transmit if retries are exhausted", " - rtc: ntxec: fix OF node reference imbalance", " - mm/damon/core: use time_in_range_open() for damos quota window start", " - userfaultfd: allow registration of ranges below mmap_min_addr", " - KVM: x86: Defer non-architectural deliver of exception payload to", " userspace read", " - KVM: nSVM: Mark all of vmcb02 dirty when restoring nested state", " - KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2", " - KVM: SVM: Explicitly mark vmcb01 dirty after modifying VMCB intercepts", " - KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest mode", " - KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXIT", " - KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN", " - KVM: nSVM: Clear GIF on nested #VMEXIT(INVALID)", " - KVM: nSVM: Clear EVENTINJ fields in vmcb12 on nested #VMEXIT", " - KVM: nSVM: Clear tracking of L1->L2 NMI and soft IRQ on nested #VMEXIT", " - KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS", " - KVM: nSVM: Add missing consistency check for nCR3 validity", " - KVM: nSVM: Always intercept VMMCALL when L2 is active", " - io_uring/poll: fix multishot recv missing EOF on wakeup race", " - perf annotate: Use jump__delete when freeing LoongArch jumps", " - mtd: spi-nor: sst: Fix write enable before AAI sequence", " - amdgpu/jpeg: fix deepsleep register for jpeg 5_0_0 and 5_0_2", " - check-uapi: link into shared objects", " - HID: apple: ensure the keyboard backlight is off if suspending", " - wifi: rtl8xxxu: fix potential use of uninitialized value", " - taskstats: set version in TGID exit notifications", " - apparmor: use target task's context in apparmor_getprocattr()", " - bus: mhi: host: pci_generic: Switch to async power up to avoid boot", " delays", " - crypto: arm64/aes - Fix 32-bit aes_mac_update() arg treated as 64-bit", " - crypto: atmel-ecc - Release client on allocation failure", " - crypto: hisilicon - Fix dma_unmap_single() direction", " - IB/core: Fix zero dmac race in neighbor resolution", " - ktest: Fix the month in the name of the failure directory", " - seg6: fix seg6 lwtunnel output redirect for L2 reduced encap mode", " - f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionally", " - ksmbd: use msleep instaed of schedule_timeout_interruptible()", " - ksmbd: replace connection list with hash table", " - ksmbd: reset rcount per connection in ksmbd_conn_wait_idle_sess_id()", " - wifi: mt76: mt792x: describe USB WFSYS reset with a descriptor", " - wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling", " - ALSA: aoa: Use guard() for mutex locks", " - ALSA: aoa: i2sbus: clear stale prepared state", " - mm/zsmalloc: copy KMSAN metadata in zs_page_migrate()", " - media: rc: ttusbir: respect DMA coherency rules", " - ALSA: aoa: Skip devices with no codecs in i2sbus_resume()", " - block: relax pgmap check in bio_add_page for compatible zone device", " pages", " - iio: frequency: admv1013: add dev variable", " - net: mctp: fix don't require received header reserved bits to be zero", " - driver core: Add kernel-doc for DEV_FLAG_COUNT enum value", " - ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path", " - ALSA: caiaq: Don't abort when no input device is available", " - ALSA: caiaq: fix usb_dev refcount leak on probe failure", " - ACPI: scan: Use acpi_dev_put() in object add error paths", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 7770 AIO", " - ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug", " - ACPI: video: force native backlight on HP OMEN 16 (8A44)", " - iommufd: Fix a race with concurrent allocation and unmap", " - spi: rockchip: fix controller deregistration", " - ksmbd: rewrite stop_sessions() with restartable iteration", " - iommu/amd: Use atomic64_inc_return() in iommu.c", " - iommu/amd: serialize sequence allocation under concurrent TLB", " invalidations", " - KVM: SVM: check validity of VMCB controls when returning from SMM", " - wifi: mt76: mt7925: fix incorrect length field in txpower command", " - wifi: mt76: mt7921: fix ROC abort flow interruption in mt7921_roc_work", " - ALSA: usb-audio: midi2: Restart output URBs on resume", " - ALSA: usb-audio: Fix UAC3 cluster descriptor size check", " - USB: omap_udc: DMA: Don't enable burst 4 mode", " - USB: serial: option: add Telit Cinterion LE910Cx compositions", " - ALSA: firewire-tascam: Do not drop unread control events", " - powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o", " - xfrm: provide message size for XFRM_MSG_MAPPING", " - selinux: don't reserve xattr slot when we won't fill it", " - selinux: shrink critical section in sel_write_load()", " - selinux: prune /sys/fs/selinux/disable", " - LoongArch: KVM: Fix missing EMULATE_FAIL in kvm_emu_mmio_read()", " - spi: syncuacer: fix controller deregistration", " - spi: sun4i: fix controller deregistration", " - spi: ti-qspi: fix controller deregistration", " - spi: sun6i: fix controller deregistration", " - spi: zynqmp-gqspi: fix controller deregistration", " - staging: vme_user: fix root device leak on init failure", " - LoongArch: Fix SYM_SIGFUNC_START definition for 32BIT", " - parisc: Fix IRQ leak in LASI driver", " - hwmon: (ltc2992) Clamp threshold writes to hardware range", " - hwmon: (ltc2992) Fix u32 overflow in power read path", " - clk: rk808: fix OF node reference imbalance", " - hwmon: (corsair-psu) Close HID device on probe errors", " - cifs: abort open_cached_dir if we don't request leases", " - cifs: change_conf needs to be called for session setup", " - extcon: ptn5150: handle pending IRQ events during system resume", " - gpio: of: clear OF_POPULATED on hog nodes in remove path", " - hv_sock: fix ARM64 support", " - spi: microchip-core-qspi: fix controller deregistration", " - udf: reject descriptors with oversized CRC length", " - thermal: core: Free thermal zone ID later during removal", " - thermal/drivers/sprd: Fix temperature clamping in", " sprd_thm_temp_to_rawdata", " - thermal/drivers/sprd: Fix raw temperature clamping in", " sprd_thm_rawdata_to_temp", " - spi: topcliff-pch: fix controller deregistration", " - clk: imx: imx8-acm: fix flags for acm clocks", " - cpuidle: powerpc: avoid double clear when breaking snooze", " - ASoC: amd: yc: Add HP OMEN Gaming Laptop 16-ap0xxx product line in quirk", " table", " - ASoC: fsl_easrc: fix comment typo", " - ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error", " - ASoC: qcom: q6apm-dai: reset queue ptr on trigger stop", " - ASoC: qcom: q6apm: remove child devices when apm is removed", " - dm: don't report warning when doing deferred remove", " - dm-verity-fec: correctly reject too-small FEC devices", " - dm-verity-fec: correctly reject too-small hash devices", " - lib/scatterlist: fix temp buffer in extract_user_to_sg()", " - nvme-apple: drop invalid put of admin queue reference count", " - openvswitch: vport: fix self-deadlock on release of tunnel ports", " - s390/debug: Reject zero-length input in debug_input_flush_fn()", " - PCI: Update saved_config_space upon resource assignment", " - PCI/AER: Clear only error bits in PCIe Device Status", " - PCI/AER: Stop ruling out unbound devices as error source", " - PCI/ASPM: Fix pci_clear_and_set_config_dword() usage", " - power: supply: max17042: avoid overflow when determining health", " - mptcp: fastclose msk when linger time is 0", " - mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure", " - mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure", " - mptcp: sockopt: set timestamp flags on subflow socket, not msk", " - f2fs: add READ_ONCE() for i_blocks in f2fs_update_inode()", " - f2fs: fix fiemap boundary handling when read extent cache is incomplete", " - f2fs: fix incorrect multidevice info in trace_f2fs_map_blocks()", " - KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value", " - KVM: arm64: Fix initialisation order in __pkvm_init_finalise()", " - LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()", " - LoongArch: KVM: Cap KVM_CAP_NR_VCPUS by KVM_CAP_MAX_VCPUS", " - LoongArch: KVM: Fix HW timer interrupt lost when inject interrupt by", " software", " - LoongArch: KVM: Move unconditional delay into timer clear scenery", " - LoongArch: KVM: Use kvm_set_pte() in kvm_flush_pte()", " - LoongArch: Use per-root-bridge PCIH flag to skip mem resource fixup", " - fs: prepare for adding LSM blob to backing_file", " - dma-mapping: drop unneeded includes from dma-mapping.h", " - dma-mapping: add __dma_from_device_group_begin()/end()", " - mmc: core: Optimize time for secure erase/trim for some Kingston eMMCs", " - mtd: spinand: winbond: Declare the QE bit on W25NxxJW", " - gtp: disable BH before calling udp_tunnel_xmit_skb()", " - printk: add print_hex_dump_devel()", " - net: stmmac: avoid shadowing global buf_sz", " - net: stmmac: rename STMMAC_GET_ENTRY() -> STMMAC_NEXT_ENTRY()", " - wifi: mt76: mt7925: fix incorrect TLV length in CLC command", " - KVM: arm64: Wake-up from WFI when iqrchip is in userspace", " - Upstream stable to v6.6.137, v6.6.138, v6.6.139, v6.12.85, v6.12.86,", " v6.12.87, v6.12.88", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43490", " - ksmbd: validate inherited ACE SID length", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46196", " - tracepoint: balance regfunc() on func_add() failure in", " tracepoint_add_func()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46110", " - net: stmmac: Prevent NULL deref when RX memory exhausted", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46090", " - ALSA: aloop: Fix peer runtime UAF during format-change stop", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46291", " - crypto: caam - guard HMAC key hex dumps in hash_digest_key", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46299", " - hfsplus: fix held lock freed on hfsplus_fill_super()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46169", " - hfsplus: fix uninit-value by validating catalog record size", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45991", " - udf: fix partition descriptor append bookkeeping", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46007", " - hwmon: (powerz) Avoid cacheline sharing for DMA buffer", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46065", " - fbdev: defio: Disconnect deferred I/O from the lifetime of struct", " fb_info", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46194", " - f2fs: fix node_cnt race between extent node destroy and writeback", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46168", " - mptcp: fix scheduling with atomic in timestamp sockopt", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46189", " - RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46133", " - RDMA/rxe: Reject unknown opcodes before ICRC processing", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46114", " - RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46127", " - RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46176", " - RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46178", " - RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46145", " - RDMA/mana: Validate rx_hash_key_len", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46126", " - RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46144", " - RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46121", " - mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46131", " - KVM: x86: check for nEPT/nNPT in slow flush hypercalls", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46139", " - smb: client: use kzalloc to zero-initialize security descriptor buffer", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46112", " - RDMA/hns: Fix unlocked call to hns_roce_qp_remove()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46292", " - pmdomain: core: Fix detach procedure for virtual devices in genpd", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46304", " - nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46135", " - nvmet-tcp: fix race between ICReq handling and queue teardown", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46161", " - md/raid10: fix divide-by-zero in setup_geo() with zero far_copies", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43492", " - lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46124", " - isofs: validate block number from NFS file handle in isofs_export_iget", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46303", " - isofs: validate Rock Ridge CE continuation extent against volume size", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46106", " - eventfs: Hold eventfs_mutex and SRCU when remount walks events", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46294", " - dm: fix a buffer overflow in ioctl processing", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46107", " - dm-thin: fix metadata refcount underflow", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46129", " - btrfs: fix double free in create_space_info() error path", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46143", " - ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46293", " - clk: microchip: mpfs-ccc: fix out of bounds access during output", " registration", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46301", " - spi: topcliff-pch: fix use-after-free on unbind", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46273", " - ibmveth: Disable GSO for packets with small MSS", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43495", " - net: wwan: t7xx: validate port_count against message length in", " t7xx_port_enum_msg_handler", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43502", " - net/rds: handle zerocopy send cleanup before the message is queued", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46120", " - ip6_gre: Use cached t->net in ip6erspan_changelink().", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46142", " - net: libwx: fix VF illegal register access", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46184", " - sound: ua101: fix division by zero at probe", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46132", " - net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in", " rtnl_fill_vfinfo", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46190", " - mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46150", " - fanotify: fix false positive on permission events", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46296", " - spi: s3c64xx: fix NULL-deref on driver unbind", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45834", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45835", " - Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46138", " - Bluetooth: hci_event: Fix OOB read and infinite loop in", " hci_le_create_big_complete_evt", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46186", " - Bluetooth: virtio_bt: validate rx pkt_type header length", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46123", " - Bluetooth: virtio_bt: clamp rx length before skb_put", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46193", " - xfrm: ah: account for ESN high bits in async callbacks", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46172", " - ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46116", " - xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46157", " - ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46146", " - ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46167", " - usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46151", " - usb: usblp: fix heap leak in IEEE 1284 device ID via short response", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46180", " - wifi: brcmfmac: Fix potential use-after-free issue when stopping", " watchdog task", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46122", " - wifi: b43: enforce bounds check on firmware key index in b43_rx()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46125", " - wifi: mac80211: remove station if connection prep fails", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46307", " - wifi: ath5k: do not access array OOB", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46187", " - wifi: rsi: fix kthread lifetime race between self-exit and external-stop", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46152", " - wifi: mac80211: drop stray 'static' from fast-RX rx_result", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46163", " - wifi: b43legacy: enforce bounds check on firmware key index in RX path", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46136", " - wifi: mt76: mt7921: fix a potential clc buffer length underflow", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46173", " - exit: prevent preemption of oopsing TASK_DEAD task", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-31499", " - Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43496", " - net/sched: sch_red: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43088", " - net: af_key: zero aligned sockaddr tail in PF_KEY exports", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46287", " - net: txgbe: fix RTNL assertion warning when remove module", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46306", " - flow_dissector: do not dissect PPPoE PFC frames", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46113", " - KVM: x86: Fix shadow paging use-after-free due to unexpected GFN", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46063", " - x86/shstk: Prevent deadlock during shstk sigreturn", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43109", " - x86: shadow stacks: proper error handling for mmap lock", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46179", " - ASoC: SOF: Don't allow pointer operations on unconfigured streams", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43497", " - fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46108", " - ipmi:si: Return state to normal if message allocation fails", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46128", " - ipmi: Check event message buffer response for bad data", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46177", " - ipmi: Add limits to event and receive message requests", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46149", " - scsi: target: configfs: Bound snprintf() return in", " tg_pt_gp_members_show()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46101", " - netfilter: reject zero shift in nft_bitwise", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46099", " - net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46276", " - drm/amdgpu: fix zero-size GDS range init on RDNA4", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46033", " - crypto: authencesn - reject short ahash digests during instance creation", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46083", " - spi: fix resource leaks on device setup failure", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46003", " - net: qrtr: ns: Limit the total number of nodes", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46086", " - net: bridge: use a stable FDB dst snapshot in RCU readers", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46026", " - net: qrtr: ns: Limit the maximum number of lookups", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43491", " - net: qrtr: ns: Limit the maximum server registration per node", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46282", " - iio: frequency: admv1013: fix NULL pointer dereference on str", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46084", " - RDMA/mana_ib: Disable RX steering on RSS QP destroy", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46091", " - media: rc: igorplugusb: heed coherency rules", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46069", " - wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46021", " - thermal: core: Fix thermal zone governor cleanup issues", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46280", " - lib: test_hmm: evict device pages on file close to avoid use-after-free", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-31715", " - f2fs: fix UAF caused by decrementing sbi->nr_pages[] in", " f2fs_write_end_io()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-31709", " - smb: client: validate the whole DACL before rewriting it in cifsacl", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45997", " - scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-43499", " - rtmutex: Use waiter::task instead of current in remove_waiter()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46062", " - ntfs3: fix integer overflow in run_unpack() volume boundary check", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46072", " - ntfs3: add buffer boundary checks to run_unpack()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46052", " - ceph: only d_add() negative dentries when they are unhashed", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46023", " - dm mirror: fix integer overflow in create_dirty_log()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46075", " - crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46077", " - crypto: atmel-tdes - fix DMA sync direction", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45986", " - crypto: ccree - fix a memory leak in cc_mac_digest()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46019", " - crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46103", " - can: ucan: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46056", " - Bluetooth: hci_event: fix potential UAF in SSP passkey handlers", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46015", " - tcp: call sk_data_ready() after listener migration", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46040", " - inotify: fix watch count leak when fsnotify_add_inode_mark_locked()", " fails", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46070", " - md/raid5: validate payload size before accessing journal metadata", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46051", " - md/raid5: fix soft lockup in retry_aligned_read()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46046", " - ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46094", " - ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46076", " - KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46082", " - KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45987", " - KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46005", " - xfs: fix a resource leak in xfs_alloc_buftarg()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46024", " - libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46037", " - ipv4: icmp: validate reply type before using icmp_pointers", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46031", " - net: ks8851: Reinstate disabling of BHs around IRQ handler", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46027", " - net/smc: avoid early lgr access in smc_clc_wait_msg", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46053", " - net: rds: fix MR cleanup on copy error", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46038", " - net: qrtr: ns: Free the node during ctrl_cmd_bye()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46012", " - rxrpc: Fix memory leaks in rxkad_verify_response()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46004", " - ALSA: caiaq: Handle probe errors properly", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46079", " - rbd: fix null-ptr-deref when device_add_disk() fails", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46016", " - remoteproc: xlnx: Only access buffer information if IPI is buffered", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46285", " - mtd: docg3: fix use-after-free in docg3_release()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46050", " - md/raid10: fix deadlock with check operation and nowait requests", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46061", " - jbd2: fix deadlock in jbd2_journal_cancel_revoke()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46078", " - erofs: fix the out-of-bounds nameoff handling for trailing dirents", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46049", " - ALSA: ctxfi: Add fallback to default RSR for S/PDIF", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46002", " - ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46047", " - net: qrtr: ns: Fix use-after-free in driver remove()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46009", " - PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46011", " - media: mtk-jpeg: fix use-after-free in release path due to uncancelled", " work", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46102", " - net: strparser: fix skb_head leak in strp_abort_strp()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46098", " - net: caif: clear client service pointer on teardown", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46088", " - ALSA: control: Validate buf_len before strnlen() in", " snd_ctl_elem_init_enum_names()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46058", " - media: amphion: Fix race between m2m job_abort and device_run", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46073", " - hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45989", " - of: unittest: fix use-after-free in testdrv_probe()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45996", " - spi: imx: fix use-after-free on unbind", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46092", " - wifi: rtw88: check for PCI upstream bridge existence", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46089", " - zram: do not forget to endio for partial discard requests", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46080", " - ocfs2: split transactions in dio completion to avoid credit exhaustion", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-23468", " - drm/amdgpu: Limit BO list entry count to prevent resource exhaustion", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46064", " - ibmasm: fix heap over-read in ibmasm_send_i2o_message()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45994", " - ibmasm: fix OOB reads in command_file_write due to missing size checks", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46022", " - misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46041", " - greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46286", " - leds: qcom-lpg: Check for array overflow when selecting the high", " resolution", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46006", " - drm/nouveau: fix u32 overflow in pushbuf reloc bounds check", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-45993", " - LoongArch: Add spectre boundry for syscall dispatch table", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2026-46018", " - ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES", "", " * Noble update: upstream stable patchset 2026-06-11 (LP: #2156549) //", " CVE-2025-54518 // CVE-2026-46174", " - x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op", " cache", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373)", " - ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA", " - ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk", " - ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC", " - media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl()", " - ALSA: asihpi: avoid write overflow check warning", " - ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF", " - ASoC: SOF: topology: reject invalid vendor array size in token parser", " - can: mcp251x: add error handling for power enable in open and resume", " - ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx", " - ALSA: hda/realtek: add quirk for Framework F111:000F", " - ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list", " - ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex", " - ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx", " - pinctrl: intel: Fix the revision for new features (1kOhm PD, HW", " debouncer)", " - platform/x86/amd: pmc: Add Thinkpad L14 Gen3 to quirk_s2idle_bug", " - HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10", " - ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585", " - ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J", " - soc: aspeed: socinfo: Mask table entries for accurate SoC ID matching", " - arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency", " - PCI: hv: Set default NUMA node to 0 for devices without affinity info", " - drm/vc4: Release runtime PM reference after binding V3D", " - drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock", " - net: stmmac: Fix PTP ref clock for Tegra234", " - dt-bindings: net: Fix Tegra234 MGBE PTP clock", " - tracing/probe: reject non-closed empty immediate strings", " - e1000: check return value of e1000_read_eeprom", " - xsk: respect tailroom for ZC setups", " - xsk: fix XDP_UMEM_SG_FLAG issues", " - selftests: net: bridge_vlan_mcast: wait for h1 before querier check", " - gpio: tegra: fix irq_release_resources calling enable instead of disable", " - ALSA: usb-audio: Improve Focusrite sample rate filtering", " - usb: storage: Expand range of matched versions for VL817 quirks entry", " - USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen", " - usb: port: add delay after usb_hub_set_port_power()", " - scripts: generate_rust_analyzer.py: avoid FD leak", " - USB: serial: option: add Telit Cinterion FN990A MBIM composition", " - Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates", " race", " - KVM: nVMX: Fold requested virtual interrupt check into", " has_nested_events()", " - net: sched: fix TCF_LAYER_TRANSPORT handling in tcf_get_base_ptr()", " - checkpatch: add support for Assisted-by tag", " - Revert \"perf unwind-libdw: Fix invalid reference counts\"", " - net: ethernet: mtk_eth_soc: initialize PPE per-tag-layer MTU registers", " - scripts: generate_rust_analyzer.py: define scripts", " - KVM: x86: Use __DECLARE_FLEX_ARRAY() for UAPI structures with VLAs", " - rxrpc: Fix key quota calculation for multitoken keys", " - ocfs2: add inline inode consistency check to", " ocfs2_validate_inode_block()", " - Revert \"wifi: cfg80211: stop NAN and P2P in cfg80211_leave\"", " - scripts/dtc: Remove unused dts_version in dtc-lexer.l", " - fuse: Check for large folio with SPLICE_F_MOVE", " - fuse: quiet down complaints in fuse_conn_limit_write", " - smb: server: fix max_connections off-by-one in tcp accept path", " - ALSA: usb-audio: apply quirk for MOONDROP JU Jiu", " - crypto: testmgr - Hide ENOENT errors", " - crypto: testmgr - Hide ENOENT errors better", " - platform/x86: asus-nb-wmi: add DMI quirk for ASUS ROG Flow Z13-KJP", " GZ302EAC", " - drm/amdgpu: Handle GPU page faults correctly on non-4K page systems", " - ALSA: hda/realtek: Add quirk for Samsung Book2 Pro 360 (NP950QED)", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9", " - net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules", " - arm64: dts: qcom: hamoa/x1: fix idle exit latency", " - HID: amd_sfh: don't log error when device discovery fails with", " -EOPNOTSUPP", " - net: increase IP_TUNNEL_RECURSION_LIMIT to 5", " - netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC ->", " GFP_KERNEL_ACCOUNT allocation", " - netfilter: nfnetlink_queue: make hash table per queue", " - thermal: core: Mark thermal zones as exiting before unregistration", " - KVM: Remove subtle \"struct kvm_stats_desc\" pseudo-overlay", " - PCI: Fix placement of pci_save_state() in pci_bus_add_device()", " - ima: verify if the segment size has changed", " - ima: do not copy measurement list to kdump kernel", " - ksmbd: fix SID memory leak in set_posix_acl_entries_dacl() on overflow", " - btrfs: tracepoints: fix sleep while in atomic context in", " btrfs_sync_file()", " - Upstream stable to v6.6.136, v6.12.83, v6.12.84", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31706", " - ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31712", " - ksmbd: require minimum ACE size in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31575", " - mm/userfaultfd: fix hugetlb fault mutex hash calculation", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31582", " - hwmon: (powerz) Fix use-after-free on USB disconnect", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43073", " - x86-64: rename misleadingly named '__copy_user_nocache()' function", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2025-21709", " - kernel: be more careful about dup_mmap() failures and uprobe registering", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31606", " - usb: gadget: f_hid: don't call cdev_init while cdev in use", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31731", " - thermal: core: Address thermal zone removal races with resume", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31677", " - crypto: af_alg - limit RX SG extraction by receive buffer budget", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43107", " - xfrm: account XFRMA_IF_ID in aevent size calculation", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43119", " - Bluetooth: hci_sync: annotate data-races around hdev->req_status", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31696", " - rxrpc: Fix missing validation of ticket length in non-XDR key preparsing", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31697", " - crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31698", " - crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command", " failed", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31699", " - crypto: ccp: Don't attempt to copy CSR to userspace if PSP command", " failed", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31700", " - net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31701", " - ALSA: caiaq: take a reference on the USB device in create_card()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31702", " - f2fs: fix use-after-free of sbi in f2fs_compress_write_end_io()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31704", " - ksmbd: use check_add_overflow() to prevent u16 DACL size overflow", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31705", " - ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31708", " - smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43350", " - smb: client: require a full NFS mode SID before reading mode bits", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31711", " - smb: server: fix active_num_conn leak on transport allocation failure", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31694", " - fuse: reject oversized dirents in page cache", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31714", " - f2fs: fix to avoid memory leak in f2fs_rename()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31716", " - fs/ntfs3: validate rec->used in journal-replay file record check", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43075", " - ocfs2: fix out-of-bounds write in ocfs2_write_end_inline", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43076", " - ocfs2: validate inline data i_size during inode read", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31595", " - PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in", " epf_ntb_epc_cleanup", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-23444", " - wifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-23442", " - ipv6: add NULL checks for idev in SRv6 paths", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31594", " - PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31576", " - media: hackrf: fix to not free memory after the device is registered in", " hackrf_probe()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43058", " - media: vidtv: fix pass-by-value structs causing MSAN warnings", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31577", " - nilfs2: fix NULL i_assoc_inode dereference in", " nilfs_mdt_save_to_shadow_map", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31578", " - media: as102: fix to not free memory after the device is registered in", " as102_usb_probe()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31580", " - bcache: fix cached_dev.sb_bio use-after-free and crash", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31581", " - ALSA: 6fire: fix use-after-free on disconnect", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31583", " - media: em28xx: fix use-after-free in em28xx_v4l2_open()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31584", " - media: mediatek: vcodec: fix use-after-free in encoder release path", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31585", " - media: vidtv: fix nfeeds state corruption on start_streaming failure", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31586", " - mm: blk-cgroup: fix use-after-free in cgwb_release_workfn()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31686", " - mm/kasan: fix double free for kasan pXds", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31587", " - ASoC: qcom: q6apm: move component registration to unmanaged version", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31588", " - KVM: x86: Use scratch field in MMIO fragment to hold small write values", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31590", " - KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31596", " - ocfs2: handle invalid dinode in ocfs2_group_extend", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31597", " - ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31598", " - ocfs2: fix possible deadlock between unlink and dio_end_io_write", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31599", " - media: vidtv: fix NULL pointer dereference in", " vidtv_channel_pmt_match_sections", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31602", " - ALSA: ctxfi: Limit PTP to a single page", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31603", " - staging: sm750fb: fix division by zero in ps_to_hz()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31604", " - wifi: rtw88: fix device leak on probe failure", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31605", " - fbdev: udlfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31610", " - ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31611", " - ksmbd: require 3 sub-authorities before reading sub_auth[2]", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31612", " - ksmbd: validate EaNameLength in smb2_get_ea()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31615", " - usb: gadget: renesas_usb3: validate endpoint index in standard request", " handlers", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31616", " - usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31617", " - usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31618", " - fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31619", " - ALSA: fireworks: bound device-supplied status before string array lookup", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43072", " - drm/vc4: platform_get_irq_byname() returns an int", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31622", " - NFC: digital: Bounds check NFC-A cascade depth in SDD response handler", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31623", " - net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31624", " - HID: core: clamp report_size in s32ton() to avoid undefined shift", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31625", " - HID: alps: fix NULL pointer dereference in alps_raw_event()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31626", " - staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31627", " - i2c: s3c24xx: check the size of the SMBUS message before using it", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31532", " - can: raw: fix ro->uniq use-after-free in raw_rcv()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31629", " - nfc: llcp: add missing return after LLCP_CLOSED checks", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31407", " - netfilter: conntrack: add missing netlink policy validations", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43079", " - perf/x86/intel/uncore: Skip discovery table for offline dies", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43080", " - l2tp: Drop large packets with UDP encap", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43345", " - net: ipa: fix event ring index not programmed for IPA v5.0+", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43081", " - net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31673", " - af_unix: read UNIX_DIAG_VFS data under unix_state_lock", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43082", " - net: txgbe: leave space for null terminators on property_entry", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31681", " - netfilter: xt_multiport: validate range encoding in checkentry", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43085", " - netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43086", " - ipvs: fix NULL deref in ip_vs_add_service error path", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43089", " - xfrm_user: fix info leak in build_mapping()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43091", " - xfrm: Wait for RCU readers during policy netns exit", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43092", " - xsk: validate MTU against usable frame size on bind", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43093", " - xsk: tighten UMEM headroom validation to account for tailroom and min", " frame", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43094", " - ixgbevf: add missing negotiate_features op to Hyper-V ops table", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43098", " - nfc: s3fwrn5: allocate rx skb before consuming bytes", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43099", " - ipv4: icmp: fix null-ptr-deref in icmp_build_probe()", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43103", " - net: lapbether: handle NETDEV_PRE_TYPE_CHANGE", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-31684", " - net: sched: act_csum: validate nested VLAN headers", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43074", " - eventpoll: defer struct eventpoll free to RCU grace period", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43104", " - drm/vc4: Fix a memory leak in hang state error path", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43105", " - drm/vc4: Fix memory leak of BO array in hang state", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43110", " - wifi: brcmfmac: validate bsscfg indices in IF events", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43111", " - HID: roccat: fix use-after-free in roccat_report_event", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43112", " - fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43113", " - wifi: wl1251: validate packet IDs before indexing tx_frames", "", " * Noble update: upstream stable patchset 2026-06-10 (LP: #2156373) //", " CVE-2026-43120", " - RDMA/irdma: Fix double free related to rereg_user_mr", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149)", " - vfio/pci: Use unmap_mapping_range()", " - gfs2: Improve gfs2_consist_inode() usage", " - Input: uinput - take event lock when submitting FF request \"event\"", " - MIPS: Always record SEGBITS in cpu_data.vmbits", " - MIPS: mm: Suppress TLB uniquification on EHINV hardware", " - MIPS: mm: Rewrite TLB uniquification for the hidden bit feature", " - virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN", " - Revert \"mptcp: add needs_id for netlink appending addr\"", " - netfilter: nft_set_pipapo: do not rely on ZERO_SIZE_PTR", " - Revert \"arm64: dts: imx8mq-librem5: Set the DVS voltages lower\"", " - arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V", " - arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity", " - arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges", " - net/mlx5: Update the list of the PCI supported devices", " - net: qualcomm: qca_uart: report the consumed byte on RX skb allocation", " failure", " - rxrpc: Fix key/keyring checks in setsockopt(RXRPC_SECURITY_KEY/KEYRING)", " - rxrpc: Fix missing error checks for rxkad encryption/decryption failure", " - Revert \"PCI: Enable ACS after configuring IOMMU for OF platforms\"", " - usb: typec: ucsi: skip connector validation before init", " - drm/i915/psr: Do not use pipe_src as borders for SU area", " - rxrpc: Fix anonymous key handling", " - ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6", " - rxrpc: Fix rxkad crypto unalignment handling", " - Upstream stable to v6.6.134, v6.6.135, v6.12.82", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31429", " - net: skb: fix cross-cache free of KFENCE-allocated skb head", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31645", " - net: lan966x: fix page pool leak in error paths", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-23302", " - net: annotate data-races around sk->sk_{data_ready,write_space}", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-23330", " - nfc: nci: complete pending data exchange on device close", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-23374", " - blktrace: fix __this_cpu_read/write in preemptible context", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31634", " - rxrpc: fix reference count leak in rxrpc_server_keyring()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31638", " - rxrpc: Only put the call ref if one was acquired", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31639", " - rxrpc: Fix key reference count leak from call->key", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31642", " - rxrpc: Fix call removal to use RCU safe deletion", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31646", " - net: lan966x: fix page_pool error handling in", " lan966x_fdma_rx_alloc_page_pool()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31648", " - mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31651", " - mmc: vub300: fix NULL-deref on disconnect", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31655", " - pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31656", " - drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31658", " - net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31689", " - EDAC/mc: Fix error path ordering in edac_mc_alloc()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31430", " - X.509: Fix out-of-bounds access when parsing extensions", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31660", " - nfc: pn533: allocate rx skb before consuming bytes", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31661", " - wifi: brcmsmac: Fix dma_free_coherent() size", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31662", " - tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31664", " - xfrm: clear trailing padding in build_polexpire()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31665", " - netfilter: nft_ct: fix use-after-free in timeout object destroy", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31667", " - Input: uinput - fix circular locking dependency with ff-core", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31670", " - net: rfkill: prevent unlimited numbers of rfkill events from being", " created", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31671", " - xfrm_user: fix info leak in build_report()", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-31672", " - wifi: rt2x00usb: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2026-43336", " - lib/crypto: chacha: Zeroize permuted_state before it leaves scope", "", " * Noble update: upstream stable patchset 2026-06-09 (LP: #2156149) //", " CVE-2025-54505 // CVE-2026-31628", " - x86/CPU: Fix FPDSS on Zen1", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958)", " - Revert \"rust: pin-init: internal: init: document load-bearing fact of", " field accessors\"", " - arm64/scs: Fix handling of advance_loc4", " - HID: logitech-hidpp: Enable MX Master 4 over bluetooth", " - btrfs: don't take device_list_mutex when querying zone info", " - tg3: replace placeholder MAC address with device property", " - objtool: Fix Clang jump table detection", " - i2c: tegra: Don't mark devices with pins as IRQ safe", " - spi: geni-qcom: Check DMA interrupts early in ISR", " - dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix", " common property warning", " - wifi: ath11k: Pass the correct value of each TID during a stop AMPDU", " session", " - net: fec: fix the PTP periodic output sysfs interface", " - tg3: Fix race for querying speed/duplex", " - net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta", " - net: enetc: check whether the RSS algorithm is Toeplitz", " - ASoC: ep93xx: Fix unchecked clk_prepare_enable() and add rollback on", " failure", " - net: introduce mangleid_features", " - net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec", " - netfilter: ipset: use nla_strcmp for IPSET_ATTR_NAME attr", " - netfilter: nf_conntrack_expect: honor expectation helper field", " - netfilter: nf_conntrack_expect: store netns and zone in expectation", " - Bluetooth: hci_sync: call destroy in hci_cmd_sync_run if immediate", " - net/mlx5: Avoid \"No data available\" when FW version queries fail", " - net: hsr: fix VLAN add unwind on slave errors", " - iio: imu: bno055: fix BNO055_SCAN_CH_COUNT off by one", " - hwmon: (pxe1610) Check return value of page-select write in probe", " - hwmon: (ltc4286) Add missing MODULE_IMPORT_NS(\"PMBUS\")", " - dt-bindings: gpio: fix microchip #interrupt-cells", " - hwmon: (tps53679) Fix device ID comparison and printing in", " tps53676_identify()", " - hwmon: (occ) Fix missing newline in occ_show_extended()", " - mips: ralink: update CPU clock index", " - sched/fair: Fix zero_vruntime tracking fix", " - riscv: kgdb: fix several debug register assignment bugs", " - USB: serial: option: add MeiG Smart SRM825WN", " - MIPS: SiByte: Bring back cache initialisation", " - MIPS: Fix the GCC version check for `__multi3' workaround", " - mips: mm: Allocate tlb_vpn array atomically", " - iio: adc: ti-adc161s626: fix buffer read on big-endian", " - drm/ast: dp501: Fix initialization of SCU2C", " - drm/i915/dp: Use crtc_state->enhanced_framing properly on ivb/hsw CPU", " eDP", " - drm/amdgpu/pm: drop SMU driver if version not matched messages", " - USB: serial: io_edgeport: add support for Blackbox IC135A", " - USB: serial: option: add support for Rolling Wireless RW135R-GL", " - USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam", " - Input: synaptics-rmi4 - fix a locking bug in an error path", " - Input: i8042 - add TUXEDO InfinityBook Max 16 Gen10 AMD to i8042 quirk", " table", " - Input: bcm5974 - recover from failed mode switch", " - Input: xpad - add support for BETOP BTP-KP50B/C controller's wireless", " mode", " - Input: xpad - add support for Razer Wolverine V3 Pro", " - iio: adc: aspeed: clear reference voltage bits before configuring vref", " - iio: accel: fix ADXL355 temperature signature value", " - iio: dac: ad5770r: fix error return in ad5770r_read_raw()", " - iio: light: vcnl4035: fix scan buffer on big-endian", " - iio: imu: bmi160: Remove potential undefined behavior in", " bmi160_config_pin()", " - iio: imu: st_lsm6dsx: Set FIFO ODR for accelerometer and gyroscope only", " - iio: gyro: mpu3050: Fix out-of-sequence free_irq()", " - usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive", " - usb: ehci-brcm: fix sleep during atomic", " - cdc-acm: new quirk for EPSON HMD", " - firmware: microchip: fail auto-update probe if no flash found", " - dt-bindings: connector: add pd-disable dependency", " - nvmem: imx: assign nvmem_cell_info::raw_len", " - gpio: mxc: map Both Edge pad wakeup to Rising Edge", " - thunderbolt: Fix property read in nhi_wake_supported()", " - usb: gadget: dummy_hcd: fix premature URB completion when ZLP follows", " partial transfer", " - btrfs: fix the qgroup data free range for inline data extents", " - usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo", " - spi: cadence-qspi: Fix exec_mem_op error handling", " - drm/amd/pm: disable OD_FAN_CURVE if temp or pwm range invalid for smu", " v13", " - s390/perf_cpum_sf: Convert to use try_cmpxchg128()", " - s390/cpum_sf: Cap sampling rate to prevent lsctl exception", " - MPTCP: fix lock class name family in pm_nl_create_listen_socket", " - drm/amd/amdgpu: decouple ASPM with pcie dpm", " - drm/amd/amdgpu: disable ASPM in some situations", " - drm/amd/display: Disable fastboot on DCE 6 too", " - drm/amd/display: Keep PLL0 running on DCE 6.0 and 6.4", " - drm/amd/display: Fix DCE 6.0 and 6.4 PLL programming.", " - drm/amd/display: Adjust DCE 8-10 clock, don't overclock by 15%", " - drm/amd/display: Disable scaling on DCE6 for now", " - drm/amd: Disable ASPM on SI", " - drm/amd/display: Correct logic check error for fastboot", " - bpf: Improve bounds when s64 crosses sign boundary", " - selftests/bpf: Test cross-sign 64bits range refinement", " - selftests/bpf: Test invariants on JSLT crossing sign", " - bpf: Add third round of bounds deduction", " - selftests/bpf: test refining u32/s32 bounds when ranges cross min/max", " boundary", " - arm64/scs: Fix potential sign extension issue of advance_loc4", " - usb: ulpi: fix memory leak on ulpi_register() error paths", " - Upstream stable to v6.6.132, v6.6.133, v6.12.81", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2025-62626", " - x86/CPU/AMD: Add additional fixed RDSEED microcode revisions", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31450", " - ext4: publish jinode after initialization", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31466", " - mm/huge_memory: fix folio isn't locked in softleaf_to_folio()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43054", " - scsi: target: tcm_loop: Drain commands in target_reset handler", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43056", " - net: mana: fix use-after-free in add_adev() error path", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43057", " - net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31695", " - wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31720", " - usb: gadget: f_uac1_legacy: validate control request size", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31721", " - usb: gadget: f_hid: move list and spinlock inits from bind to alloc", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31722", " - usb: gadget: f_rndis: Fix net_device lifecycle with device_move", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31723", " - usb: gadget: f_subset: Fix net_device lifecycle with device_move", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31724", " - usb: gadget: f_eem: Fix net_device lifecycle with device_move", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31725", " - usb: gadget: f_ecm: Fix net_device lifecycle with device_move", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43342", " - usb: gadget: f_rndis: Protect RNDIS options with mutex", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43343", " - usb: gadget: f_subset: Fix unbalanced refcnt in geth_free", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31726", " - usb: gadget: uvc: fix NULL pointer dereference during unbind race", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31728", " - usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2025-71269", " - btrfs: do not free data reservation in fallback from inline due to", " -ENOSPC", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-23389", " - ice: Fix memory leak in ice_set_ringparam()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31729", " - usb: typec: ucsi: validate connector number in ucsi_notify_common()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43324", " - USB: dummy-hcd: Fix interrupt synchronization error", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43327", " - USB: dummy-hcd: Fix locking/synchronization error", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31730", " - misc: fastrpc: possible double-free of cctx->remote_heap", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43332", " - thermal: core: Fix thermal zone device registration error path", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43328", " - cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error", " path", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31737", " - net: ftgmac100: fix ring allocation unwind on open failure", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31738", " - vxlan: validate ND option lengths in vxlan_na_create", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31740", " - counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31741", " - counter: rz-mtu3-cnt: prevent counter from being toggled multiple times", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31747", " - comedi: me4000: Fix potential overrun of firmware buffer", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31748", " - comedi: me_daq: Fix potential overrun of firmware buffer", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31749", " - comedi: ni_atmio16d: Fix invalid clean-up after failed attach", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43340", " - comedi: Reinit dev->spinlock between attachments to low-level drivers", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31751", " - comedi: dt2815: add hardware detection to prevent crash", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31752", " - bridge: br_nd_send: validate ND option lengths", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31754", " - usb: cdns3: gadget: fix state inconsistency on gadget init failure", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31755", " - usb: cdns3: gadget: fix NULL pointer dereference in ep_queue", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31756", " - usb: dwc2: gadget: Fix spin_lock/unlock mismatch in", " dwc2_hsotg_udc_stop()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31758", " - usb: usbtmc: Flush anchored URBs in usbtmc_release", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31759", " - usb: ulpi: fix double free in ulpi_register_interface() error path", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31761", " - iio: gyro: mpu3050: Move iio_device_register() to correct location", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31762", " - iio: gyro: mpu3050: Fix irq resource leak", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31763", " - iio: gyro: mpu3050: Fix incorrect free_irq() variable", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31767", " - drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31768", " - iio: adc: ti-adc161s626: use DMA-safe memory for spi_read()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31770", " - hwmon: (occ) Fix division by zero in occ_show_power_1()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31432", " - ksmbd: fix OOB write in QUERY_INFO for compound requests", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31772", " - Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43334", " - Bluetooth: SMP: force responder MITM requirements before building the", " pairing response", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31773", " - Bluetooth: SMP: derive legacy responder STK authentication from MITM", " state", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31776", " - ALSA: ctxfi: Fix missing SPDIFI1 index handling", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31778", " - ALSA: caiaq: fix stack out-of-bounds read in init_card", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31779", " - wifi: iwlwifi: mvm: fix potential out-of-bounds read in", " iwl_mvm_nd_match_info_handler()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31780", " - wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31781", " - drm/ioc32: stop speculation on the drm_compat_ioctl path", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43007", " - accel/qaic: Handle DBC deactivation if the owner went away", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43333", " - bpf: reject direct access to nullable PTR_TO_BUF pointers", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31415", " - ipv6: avoid overflows in ip6_datagram_send_ctl()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31422", " - net/sched: cls_flow: fix NULL pointer dereference on shared blocks", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31421", " - net/sched: cls_fw: fix NULL pointer dereference on shared blocks", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31417", " - net/x25: Fix overflow when accumulating packets", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43012", " - net/mlx5: Fix switchdev mode rollback in case of failure", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43013", " - net/mlx5: lag: Check for LAG device before creating debugfs", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43014", " - net: macb: properly unregister fixed rate clocks", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43015", " - net: macb: fix clk handling on PCI glue driver removal", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31675", " - net/sched: sch_netem: fix out-of-bounds access in packet corruption", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43016", " - bpf: sockmap: Fix use-after-free of sk->sk_socket in", " sk_psock_verdict_data_ready().", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31425", " - rds: ib: reject FRMR registration before IB connection is established", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43017", " - Bluetooth: MGMT: validate mesh send advertising payload length", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43018", " - Bluetooth: hci_event: fix potential UAF in", " hci_le_remote_conn_param_req_evt", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43019", " - Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43020", " - Bluetooth: MGMT: validate LTK enc_size on load", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43023", " - Bluetooth: SCO: fix race conditions in sco_sock_connect()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43024", " - netfilter: nf_tables: reject immediate NF_QUEUE verdict", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31424", " - netfilter: x_tables: restrict xt_check_match/xt_check_target extensions", " for NFPROTO_ARP", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43025", " - netfilter: ctnetlink: ignore explicit helper on new expectations", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31414", " - netfilter: nf_conntrack_expect: use expect->helper", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43026", " - netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43027", " - netfilter: nf_conntrack_helper: pass helper to expect cleanup", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43028", " - netfilter: x_tables: ensure names are nul-terminated", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31416", " - netfilter: nfnetlink_log: account for netlink header size", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43329", " - netfilter: flowtable: strictly check for maximum number of actions", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31680", " - net: ipv6: flowlabel: defer exclusive option free until RCU teardown", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43030", " - bpf: Fix regsafe() for pointers to packet", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43032", " - NFC: pn533: bound the UART receive buffer", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43035", " - net: sched: cls_api: fix tc_chain_fill_node to initialize tcm_info to", " zero to prevent an info-leak", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43036", " - net: use skb_header_pointer() for TCPv4 GSO frag_off check", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43339", " - ipv6: prevent possible UaF in addrconf_permanent_addr()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-31423", " - net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43040", " - net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX", " fields to zero to prevent an info-leak", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43041", " - net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory", " leak", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43043", " - crypto: af-alg - fix NULL pointer dereference in scatterwalk", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43330", " - crypto: caam - fix overflow on long hmac keys", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43044", " - crypto: caam - fix DMA corruption on long hmac keys", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43046", " - btrfs: reject root items with drop_progress and zero drop_level", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43338", " - btrfs: reserve enough transaction items for qgroup ioctls", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43047", " - HID: multitouch: Check to ensure report responses match the request", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43049", " - HID: logitech-hidpp: Prevent use-after-free on force feedback", " initialisation failure", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43050", " - atm: lec: fix use-after-free in sock_def_readable()", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43051", " - HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq", "", " * Noble update: upstream stable patchset 2026-06-08 (LP: #2155958) //", " CVE-2026-43052", " - wifi: mac80211: check tdls flag in ieee80211_tdls_oper", "", " * Noble update: upstream stable patchset 2026-06-05 (LP: #2155660)", " - perf: Extract a few helpers", " - perf: Make sure to use pmu_ctx->pmu for groups", " - cxl/hdm: Avoid incorrect DVSEC fallback when HDM decoders are enabled", " - hwmon: (axi-fan-control) Use device firmware agnostic API", " - hwmon: (axi-fan-control) Make use of dev_err_probe()", " - hwmon: axi-fan: don't use driver_override as IRQ name", " - sh: platform_early: remove pdev->driver_override check", " - bpf: Release module BTF IDR before module unload", " - bpf: Fix undefined behavior in interpreter sdiv/smod for INT_MIN", " - HID: asus: avoid memory leak in asus_report_fixup()", " - platform/x86: intel-hid: Add Dell 14 Plus 2-in-1 to dmi_vgbs_allow_list", " - nvme-pci: cap queue creation to used queues", " - nvme-fabrics: use kfree_sensitive() for DHCHAP secrets", " - platform/x86: intel-hid: Enable 5-button array on ThinkPad X1 Fold 16", " Gen 1", " - platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix", " touchscreen on SUPI S10", " - nvme-pci: ensure we're polling a polled queue", " - HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2", " - HID: magicmouse: avoid memory leak in magicmouse_report_fixup()", " - net: usb: r8152: add TRENDnet TUC-ET2G", " - HID: mcp2221: cancel last I2C command on read error", " - HID: asus: add xg mobile 2023 external hardware support", " - module: Fix kernel panic when a symbol st_shndx is out of bounds", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_set_reg()", " - ASoC: fsl_easrc: Fix event generation in fsl_easrc_iec958_put_bits()", " - dma-buf: Include ioctl.h in UAPI header", " - HID: apple: avoid memory leak in apple_report_fixup()", " - btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create", " - ALSA: hda/realtek: add HP Laptop 14s-dr5xxx mute LED quirk", " - ALSA: hda/realtek: Add headset jack quirk for Thinkpad X390", " - objtool: Handle Clang RSP musical chairs", " - usb: core: new quirk to handle devices with zero configurations", " - spi: intel-pci: Add support for Nova Lake mobile SPI flash", " - xfrm: call xdo_dev_state_delete during state update", " - xfrm: Fix the usage of skb->sk", " - esp: fix skb leak with espintcp and async crypto", " - af_key: validate families in pfkey_send_migrate()", " - dma: swiotlb: add KMSAN annotations to swiotlb_bounce()", " - can: statistics: add missing atomic access in hot path", " - Bluetooth: L2CAP: Validate PDU length before reading SDU length in", " l2cap_ecred_data_rcv()", " - Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing", " sock_hold", " - Bluetooth: hci_ll: Fix firmware leak on error path", " - Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb", " - pinctrl: mediatek: common: Fix probe failure for devices without EINT", " - ionic: fix persistent MAC address override on PF", " - nfc: nci: fix circular locking dependency in nci_close_device", " - net: openvswitch: Avoid releasing netdev before teardown completes", " - openvswitch: defer tunnel netdev_put to RCU release", " - openvswitch: validate MPLS set/set_masked payload length", " - net/smc: fix double-free of smc_spd_priv when tee() duplicates splice", " pipe buffer", " - rtnetlink: count IFLA_INFO_SLAVE_KIND in if_nlmsg_size", " - platform/olpc: olpc-xo175-ec: Fix overflow error message to print inlen", " - ice: use ice_update_eth_stats() for representor stats", " - ipv6: Remove permanent routes from tb6_gc_hlist when all exceptions", " expire.", " - ipv6: Don't remove permanent routes with exceptions from tb6_gc_hlist.", " - tcp: optimize inet_use_bhash2_on_bind()", " - udp: Fix wildcard bind conflict check when using hash2", " - net: enetc: fix the output issue of 'ethtool --show-ring'", " - dma-mapping: add missing `inline` for `dma_free_attrs`", " - Bluetooth: L2CAP: Fix send LE flow credits in ACL link", " - Bluetooth: Remove 3 repeated macro definitions", " - Bluetooth: hci_sync: Remove remaining dependencies of hci_request", " - Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lock", " - Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop", " - Bluetooth: btusb: clamp SCO altsetting table indices", " - tls: Purge async_hold in tls_decrypt_async_wait()", " - netfilter: nfnetlink_log: fix uninitialized padding leak in", " NFULA_PAYLOAD", " - netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()", " - netfilter: nf_conntrack_expect: skip expectations in other netns via", " proc", " - netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in", " process_sdp", " - netfilter: ctnetlink: use netlink policy range checks", " - net: macb: use the current queue number for stats", " - regmap: Synchronize cache for the page selector", " - RDMA/rw: Fall back to direct SGE on MR pool exhaustion", " - RDMA/irdma: Initialize free_qp completion before using it", " - RDMA/irdma: Update ibqp state to error if QP is already in error state", " - RDMA/irdma: Remove a NOP wait_event() in irdma_modify_qp_roce()", " - RDMA/irdma: Clean up unnecessary dereference of event->cm_node", " - RDMA/irdma: Remove reset check from irdma_modify_qp_to_err()", " - RDMA/irdma: Fix deadlock during netdev reset with active connections", " - RDMA/irdma: Return EINVAL for invalid arp index error", " - scsi: scsi_transport_sas: Fix the maximum channel scanning issue", " - x86/efi: efi_unmap_boot_services: fix calculation of ranges_to_free size", " - drm/i915/gmbus: fix spurious timeout on 512-byte burst reads", " - PM: hibernate: Don't ignore return from set_memory_ro()", " - PM: hibernate: Drain trailing zero pages on userspace restore", " - spi: sn-f-ospi: Fix resource leak in f_ospi_probe()", " - ASoC: Intel: catpt: Fix the device initialization", " - ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()", " - drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib", " - hwmon: (adm1177) fix sysfs ABI violation and current unit conversion", " - sysctl: fix uninitialized variable in proc_do_large_bitmap", " - ASoC: adau1372: Fix unchecked clk_prepare_enable() return value", " - ASoC: adau1372: Fix clock leak on PLL lock failure", " - spi: spi-fsl-lpspi: fix teardown order issue (UAF)", " - s390/syscalls: Add spectre boundary for syscall dispatch table", " - s390/barrier: Make array_index_mask_nospec() __always_inline", " - ksmbd: fix potencial OOB in get_file_all_info() for compound requests", " - ksmbd: do not expire session on binding failure", " - ALSA: firewire-lib: fix uninitialized local variable", " - ASoC: SOF: ipc4-topology: Allow bytes controls without initial payload", " - can: gw: fix OOB heap access in cgw_csum_crc8_rel()", " - can: isotp: fix tx.buf use-after-free in isotp_sendmsg()", " - cpufreq: conservative: Reset requested_freq on limits change", " - platform/x86: ISST: Correct locked bit width", " - KVM: arm64: Discard PC update state on vcpu reset", " - hwmon: (pmbus/isl68137) Add mutex protection for AVS enable sysfs", " attributes", " - hwmon: (peci/cputemp) Fix crit_hyst returning delta instead of absolute", " temperature", " - hwmon: (peci/cputemp) Fix off-by-one in cputemp_is_visible()", " - media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex", " - virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and", " napi_tx is false", " - s390/entry: Scrub r12 register on kernel entry", " - erofs: add GFP_NOIO in the bio completion if needed", " - alarmtimer: Fix argument order in alarm_timer_forward()", " - scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()", " - scsi: ses: Handle positive SCSI error from ses_recv_diag()", " - net: macb: Use dev_consume_skb_any() to free TX SKBs", " - KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO", " SPTE", " - jbd2: gracefully abort on checkpointing state corruptions", " - irqchip/qcom-mpm: Add missing mailbox TX done acknowledgment", " - dmaengine: sh: rz-dmac: Protect the driver specific lists", " - dmaengine: sh: rz-dmac: Move CHCTRL updates under spinlock", " - LoongArch: Workaround LS2K/LS7A GPU DMA hang bug", " - xfs: stop reclaim before pushing AIL during unmount", " - xfs: fix ri_total validation in xlog_recover_attri_commit_pass2", " - ext4: fix journal credit check when setting fscrypt context", " - ext4: convert inline data to extents when truncate exceeds inline size", " - ext4: fix fsync(2) for nojournal mode", " - ext4: make recently_deleted() properly work with lazy itable", " initialization", " - ext4: replace BUG_ON with proper error handling in", " ext4_read_inline_folio", " - ext4: avoid allocate block from corrupted group in", " ext4_mb_find_by_goal()", " - ext4: reject mount if bigalloc with s_first_data_block != 0", " - ext4: fix use-after-free in update_super_work when racing with umount", " - ext4: fix the might_sleep() warnings in kvfree()", " - ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths", " - ext4: always drain queued discard work in ext4_mb_release()", " - arm64: dts: imx8mn-tqma8mqnl: fix LDO5 power off", " - powerpc64/bpf: do not increment tailcall count when prog is NULL", " - ksmbd: fix memory leaks and NULL deref in smb2_lock()", " - tracing: Switch trace_osnoise.c code over to use guard() and __free()", " - tracing: Fix potential deadlock in cpu hotplug with osnoise", " - mtd: spi-nor: core: avoid odd length/address reads on 8D-8D-8D mode", " - mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D mode", " - libbpf: Fix -Wdiscarded-qualifiers under C23", " - mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]", " - xfs: avoid dereferencing log items after push callbacks", " - xfs: save ailp before dropping the AIL lock in push callbacks", " - dmaengine: idxd: Fix not releasing workqueue on .release()", " - dmaengine: idxd: Fix memory leak when a wq is reset", " - phy: ti: j721e-wiz: Fix device node reference leak in", " wiz_get_lane_phy_types()", " - dmaengine: dw-edma: Fix multiple times setting of the CYCLE_STATE and", " CYCLE_BIT bits for HDMA.", " - dmaengine: xilinx: xdma: Fix regmap init error handling", " - dmaengine: xilinx: xilinx_dma: Fix dma_device directions", " - dmaengine: xilinx: xilinx_dma: Fix residue calculation for cyclic DMA", " - dmaengine: xilinx: xilinx_dma: Fix unmasked residue subtraction", " - dmaengine: xilinx_dma: Fix reset related timeout with two-channel AXIDMA", " - btrfs: fix super block offset in error message in btrfs_validate_super()", " - btrfs: fix leak of kobject name for sub-group space_info", " - btrfs: fix lost error when running device stats on multiple devices fs", " - dmaengine: idxd: Fix freeing the allocated ida too late", " - futex: Clear stale exiting pointer in futex_lock_pi() retry path", " - ALSA: hda/realtek: Fix speaker pop on Star Labs StarFighter", " - kexec: Consolidate machine_kexec_mask_interrupts() implementation", " - [Config] Enable GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD by default.", " - kexec: Include kernel-end even without crashkernel", " - powerpc/kexec/core: use big-endian types for crash variables", " - drm/msm/dsi: fix hdisplay calculation when programming dsi registers", " - perf disasm: Fix off-by-one bug in outside check", " - net/mlx5: Fix crash when moving to switchdev mode", " - bonding: add ESP offload features when slaves support", " - bonding: Correctly support GSO ESP offload", " - net: add a common function to compute features for upper devices", " - bonding: use common function to compute the features", " - bonding: fix type confusion in bond_setup_by_slave()", " - xdp: allow attaching already registered memory model to xdp_rxq_info", " - net: add generic percpu page_pool allocator", " - net: do not consume a cacheline for system_page_pool", " - xdp: register system page pool as an XDP memory model", " - net: add xmit recursion limit to tunnel xmit functions", " - net: prevent NULL deref in ip[6]tunnel_xmit()", " - ata: libata-core: Add BRIDGE_OK quirk for QEMU drives", " - usb: typec: altmode/displayport: set displayport signaling rate in", " configure message", " - rust: kbuild: allow `unused_features`", " - ceph: add a bunch of missing ceph_path_info initializers", " - drm/amd/pm: remove invalid gpu_metrics.energy_accumulator on smu v13.0.x", " - tracing: Fix enabling multiple events on the kernel command line and", " bootconfig", " - qmi_wwan: allow max_mtu above hard_mtu to control rx_urb_size", " - xfs: fix returned valued from xfs_defer_can_append", " - iio: imu: inv_icm42600: add support of ICM-42686-P", " - iio: imu: inv_icm42600: fix odr switch when turning buffer off", " - perf/x86/intel/uncore: Support more units on Granite Rapids", " - perf/x86/intel/uncore: Add per-scheduler IMC CAS count events", " - cleanup: Provide retain_and_null_ptr()", " - usb: gadget: f_ncm: Fix net_device lifecycle with device_move", " - KVM: x86: Co-locate initialization of feature MSRs in", " kvm_arch_vcpu_create()", " - KVM: x86: Quirk initialization of feature MSRs to KVM's max", " configuration", " - KVM: x86: do not allow re-enabling quirks", " - KVM: x86: Allow vendor code to disable quirks", " - KVM: x86: Introduce supported_quirks to block disabling quirks", " - KVM: x86: Remove VMX support for virtualizing guest MTRR memtypes", " - KVM: VMX: Drop support for forcing UC memory when guest CR0.CD=1", " - KVM: x86: Introduce Intel specific quirk KVM_X86_QUIRK_IGNORE_GUEST_PAT", " - KVM: nVMX: Add consistency checks for CR0.WP and CR4.CET", " - KVM: x86: Introduce KVM_X86_QUIRK_VMCS12_ALLOW_FREEZE_IN_SMM", " - drm/xe/sync: Cleanup partially initialized sync on parse failure", " - ice: fix devlink reload call trace", " - io_uring/uring_cmd: fix too strict requirement on ioctl", " - erofs: fix inline data read failure for ztailpacking pclusters", " - mm: merge folio_is_secretmem() and folio_fast_pin_allowed() into", " gup_fast_folio_allowed()", " - mm: thp: deny THP for files on anonymous inodes", " - sched/fair: Fix zero_vruntime tracking", " - mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations", " - drm/i915/dsc: Add Selective Update register definitions", " - drm/imagination: Fix deadlock in soft reset sequence", " - ata: libata-scsi: Return residual for emulated SCSI commands", " - ata: libata-scsi: report correct sense field pointer in", " ata_scsiop_maint_in()", " - soc: microchip: mpfs: Fix memory leak in mpfs_sys_controller_probe()", " - firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap()", " - Bluetooth: MGMT: Fix list corruption and UAF in command complete", " handlers", " - nf_tables: nft_dynset: fix possible stateful expression memleak in error", " path", " - bonding: prevent potential infinite loop in bond_header_parse()", " - drm/i915/psr: Compute PSR entry_setup_frames into intel_crtc_state", " - perf/x86/intel: Add missing branch counters constraint apply", " - Revert \"LoongArch: Add machine_kexec_mask_interrupts() implementation\"", " - cxl/port: Fix use after free of parent_port in cxl_detach_ep()", " - driver core: generalize driver_override in struct device", " - driver core: platform: use generic driver_override infrastructure", " - bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR", " - HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list", " - kbuild: install-extmod-build: Package resolve_btfids if necessary", " - nvmet: move async event work off nvmet-wq", " - ALSA: hda/realtek: add quirk for ASUS UM6702RC", " - i3c: master: dw-i3c: Fix missing of_node for virtual I2C adapter", " - xfrm: add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi", " - xfrm: fix the condition on x->pcpu_num in xfrm_sa_len", " - xfrm: prevent policy_hthresh.work from racing with netns teardown", " - Bluetooth: MGMT: Fix dangling pointer on", " mgmt_add_adv_patterns_monitor_complete", " - net: bcmasp: remove eee_enabled/eee_active in bcmasp_get_eee()", " - net: bcm: asp2: fix LPI timer handling", " - net: bcm: asp2: remove tx_lpi_enabled", " - net: bcmasp: Add support for ASP 2.2", " - net: bcm: asp2: convert to phylib managed EEE", " - net: bcmasp: Remove support for asp-v2.0", " - net: bcmasp: streamline early exit in probe", " - net: bcmasp: fix double free of WoL irq", " - net: bcmasp: Add support for asp-v3.0", " - net: bcmasp: fix double disable of clk", " - platform/x86: intel-hid: disable wakeup_mode during hibernation", " - iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()", " - team: fix header_ops type confusion with non-Ethernet ports", " - ALSA: hda/realtek: Sequence GPIO2 on Star Labs StarFighter", " - spi: meson-spicc: Fix double-put in remove path", " - drm/amd/display: Do not skip unrelated mode changes in DSC validation", " - spi: Group CS related fields in struct spi_device", " - spi: use generic driver_override infrastructure", " - hwmon: (pmbus/core) Fix various coding style issues", " - hwmon: (pmbus) Mark lowest/average/highest/rated attributes as read-only", " - hwmon: (pmbus) Introduce the concept of \"write-only\" attributes", " - x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling()", " - ovl: fix wrong detection of 32bit inode numbers", " - net: macb: Move devm_{free,request}_irq() out of spin lock area", " - dmaengine: fsl-edma: change to guard(mutex) within fsl_edma3_xlate()", " - dmaengine: fsl-edma: fix channel parameter config for fixed channel", " requests", " - LoongArch: Fix missing NULL checks for kstrdup()", " - xfs: scrub: unlock dquot before early return in quota scrub", " - ext4: validate p_idx bounds in ext4_ext_correct_indexes", " - LoongArch: vDSO: Emit GNU_EH_FRAME correctly", " - spi: tegra210-quad: Protect curr_xfer check in IRQ handler", " - media: nxp: imx8-isi: Fix streaming cleanup on release", " - rust: pin-init: internal: init: document load-bearing fact of field", " accessors", " - ovl: Use str_on_off() helper in ovl_show_options()", " - ovl: make fsync after metadata copy-up opt-in mount option", " - virt: tdx-guest: Fix handling of host controlled 'quote' buffer length", " - net: add proper RCU protection to /proc/net/ptype", " - landlock: Optimize file path walks and prepare for audit support", " - landlock: Fix handling of disconnected directories", " - idpf: check error for register_netdev() on init", " - idpf: detach and close netdevs while handling a reset", " - idpf: Fix RSS LUT NULL pointer crash on early ethtool operations", " - idpf: Fix RSS LUT NULL ptr issue after soft reset", " - ASoC: ak4458: Convert to RUNTIME_PM_OPS() & co", " - netfs: Fix kernel BUG in netfs_limit_iter() for ITER_KVEC iterators", " - xen/privcmd: unregister xenstore notifier on module exit", " - futex: Require sys_futex_requeue() to have identical flags", " - dmaengine: idxd: Fix leaking event log memory", " - net: bcmasp: Restore programming of TX map vector register", " - net: bcmasp: Fix network filter wake for asp-3.0", " - idpf: nullify pointers after they are freed", " - Upstream stable to v6.6.131, v6.12.78, v6.12.79, v6.12.80", "", " * Noble update: upstream stable patchset 2026-05-28 (LP: #2154496)", " - drm/vmwgfx: Fix invalid kref_put callback in vmw_bo_dirty_release", " - drm/vmwgfx: Return the correct value in vmw_translate_ptr functions", " - drm/logicvc: Fix device node reference leak in", " logicvc_drm_config_parse()", " - irqchip/sifive-plic: Fix frozen interrupt due to affinity setting", " - scsi: lpfc: Properly set WC for DPP mapping", " - scsi: pm8001: Fix use-after-free in pm8001_queue_command()", " - ALSA: usb-audio: Remove VALIDATE_RATES quirk for Focusrite devices", " - rseq: Clarify rseq registration rseq_size bound check comment", " - scsi: ufs: core: Move link recovery for hibern8 exit failure to", " wl_resume", " - ALSA: usb-audio: Cap the packet size pre-calculations", " - ALSA: usb-audio: Use inclusive terms", " - perf: Fix __perf_event_overflow() vs perf_remove_from_context() race", " - ALSA: pci: hda: use snd_kcontrol_chip()", " - ALSA: hda: cs35l56: Fix signedness error in cs35l56_hda_posture_put()", " - btrfs: fix incorrect key offset in error message in", " check_dev_extent_item()", " - btrfs: fix objectid value in error message in check_extent_data_ref()", " - btrfs: fix warning in scrub_verify_one_metadata()", " - btrfs: fix compat mask in error messages in btrfs_check_features()", " - bpf: Fix stack-out-of-bounds write in devmap", " - PCI: Correct PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 value", " - memory: mtk-smi: fix device leaks on common probe", " - memory: mtk-smi: fix device leak on larb probe", " - resource: Add resource set range and size helpers", " - PCI: Use resource_set_range() that correctly sets ->end", " - KVM: x86: Rename KVM_MSR_RET_INVALID to KVM_MSR_RET_UNSUPPORTED", " - media: tegra-video: Fix memory leak in __tegra_channel_try_format()", " - KVM: x86: WARN if a vCPU gets a valid wakeup that KVM can't yet inject", " - KVM: x86: Ignore -EBUSY when checking nested events from vcpu_block()", " - drm/tegra: dsi: fix device leak on probe", " - ext4: get rid of ppath in ext4_split_extent_at()", " - ext4: subdivide EXT4_EXT_DATA_VALID1", " - ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1", " - ext4: get rid of ppath in ext4_split_extent()", " - ext4: get rid of ppath in ext4_split_convert_extents()", " - ext4: get rid of ppath in ext4_convert_unwritten_extents_endio()", " - ext4: get rid of ppath in ext4_ext_convert_to_initialized()", " - ext4: get rid of ppath in ext4_ext_handle_unwritten_extents()", " - ext4: correct the comments place for EXT4_EXT_MAY_ZEROOUT", " - ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting", " I/O", " - ext4: drop extent cache after doing PARTIAL_VALID1 zeroout", " - ext4: drop extent cache when splitting extent fails", " - mailbox: Use of_property_match_string() instead of open-coding", " - mailbox: don't protect of_parse_phandle_with_args with con_mutex", " - mailbox: sort headers alphabetically", " - mailbox: remove unused header files", " - mailbox: Use dev_err when there is error", " - mailbox: Use guard/scoped_guard for con_mutex", " - mailbox: Allow controller specific mapping using fwnode", " - mailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()", " - ext4: convert bd_bitmap_page to bd_bitmap_folio", " - ext4: convert bd_buddy_page to bd_buddy_folio", " - ext4: fix e4b bitmap inconsistency reports", " - arm64: dts: rockchip: Fix rk356x PCIe range mappings", " - clk: tegra: tegra124-emc: fix device leak on set_rate()", " - usb: cdns3: remove redundant if branch", " - usb: cdns3: call cdns_power_is_lost() only once in cdns_resume()", " - usb: cdns3: fix role switching during resume", " - drm/amd: Fix hang on amdgpu unload by using pci_dev_is_disconnected()", " - ALSA: hda/conexant: Add quirk for HP ZBook Studio G4", " - hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization", " induced race", " - ALSA: hda/conexant: Fix headphone jack handling on Acer Swift SF314", " - net: arcnet: com20020-pci: fix support for 2.5Mbit cards", " - eventpoll: Fix integer overflow in ep_loop_check_proc()", " - media: dvb-core: fix wrong reinitialization of ringbuffer on reopen", " - nfc: pn533: properly drop the usb interface reference on disconnect", " - net: usb: kaweth: validate USB endpoints", " - net: usb: kalmia: validate USB endpoints", " - net: usb: pegasus: validate USB endpoints", " - can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a", " message", " - can: usb: f81604: correctly anchor the urb in the read bulk callback", " - can: ucan: Fix infinite loop from zero-length messages", " - can: usb: etas_es58x: correctly anchor the urb in the read bulk callback", " - can: usb: f81604: handle short interrupt urb messages properly", " - can: usb: f81604: handle bulk write errors properly", " - HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them", " - x86/efi: defer freeing of boot services memory", " - platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data", " - platform/x86: dell-wmi: Add audio/mic mute key codes", " - ALSA: usb-audio: Use correct version for UAC3 header validation", " - wifi: radiotap: reject radiotap with unknown bits", " - wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()", " - wifi: mac80211: bounds-check link_id in ieee80211_ml_reconfiguration", " - wifi: mac80211: fix NULL pointer dereference in mesh_rx_csa_frame()", " - IB/mthca: Add missed mthca_unmap_user_db() for mthca_create_srq()", " - RDMA/irdma: Fix kernel stack leak in irdma_create_user_ah()", " - net/sched: ets: fix divide by zero in the offload path", " - scsi: target: Fix recursive locking in __configfs_open_file()", " - Squashfs: check metadata block offset is within range", " - drbd: fix \"LOGIC BUG\" in drbd_al_begin_io_nonblock()", " - drbd: fix null-pointer dereference on local read error", " - smb: client: fix cifs_pick_channel when channels are equally loaded", " - smb: client: fix broken multichannel with krb5+signing", " - smb: client: Don't log plaintext credentials in cifs_set_cifscreds", " - scsi: core: Fix refcount leak for tagset_refcnt", " - selftests: mptcp: more stable simult_flows tests", " - selftests: mptcp: join: check removing signal+subflow endp", " - ARM: clean up the memset64() C wrapper", " - hwmon: (aht10) Add support for dht20", " - hwmon: (aht10) Fix initialization commands for AHT20", " - pinctrl: equilibrium: rename irq_chip function callbacks", " - pinctrl: equilibrium: fix warning trace on load", " - platform/x86: thinkpad_acpi: Fix errors reading battery thresholds", " - pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe()", " - hwmon: (it87) Check the it87_lock() return value", " - e1000e: clear DPG_EN after reset to avoid autonomous power-gating", " - drm/solomon: Fix page start when updating rectangle in page addressing", " mode", " - net: ethernet: ti: am65-cpsw-nuss/cpsw-ale: Fix multicast entry handling", " in ALE table", " - xsk: Get rid of xdp_buff_xsk::xskb_list_node", " - xsk: s/free_list_node/list_node/", " - xsk: Fix fragment node deletion to prevent buffer leak", " - xsk: Fix zero-copy AF_XDP fragment drop", " - dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ", " handler", " - atm: lec: fix null-ptr-deref in lec_arp_clear_vccs", " - amd-xgbe: fix MAC_TCR_SS register width for 2.5G and 10M speeds", " - can: bcm: fix locking for bcm_op runtime updates", " - can: mcp251x: fix deadlock in error path of mcp251x_open", " - rust: kunit: fix warning when !CONFIG_PRINTK", " - kunit: tool: copy caller args in run_kernel to prevent mutation", " - net: dsa: realtek: rtl8365mb: fix rtl8365mb_phy_ocp_write return value", " - bpf/bonding: reject vlan+srcmac xmit_hash_policy change when XDP is", " loaded", " - octeon_ep: Relocate counter updates before NAPI", " - octeon_ep: avoid compiler and IQ/OQ reordering", " - wifi: cw1200: Fix locking in error paths", " - wifi: wlcore: Fix a locking bug", " - wifi: mt76: mt7996: Fix possible oob access in", " mt7996_mac_write_txwi_80211()", " - wifi: mt76: Fix possible oob access in", " mt76_connac2_mac_write_txwi_80211()", " - indirect_call_wrapper: do not reevaluate function pointer", " - net/rds: Fix circular locking dependency in rds_tcp_tune", " - xen/acpi-processor: fix _CST detection using undersized evaluation", " buffer", " - bpf: export bpf_link_inc_not_zero.", " - bpf: Fix a UAF issue in bpf_trampoline_link_cgroup_shim", " - smb/client: fix buffer size for smb311_posix_qinfo in smb2_compound_op()", " - smb/client: fix buffer size for smb311_posix_qinfo in", " SMB311_posix_query_info()", " - ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()", " - amd-xgbe: fix sleep while atomic on suspend/resume", " - drm/sched: Fix kernel-doc warning for drm_sched_job_done()", " - nvme: reject invalid pr_read_keys() num_keys values", " - nvme: fix memory allocation in nvme_pr_read_keys()", " - net: sched: avoid qdisc_reset_all_tx_gt() vs dequeue race for lockless", " qdiscs", " - net: nfc: nci: Fix zero-length proprietary notifications", " - nfc: nci: free skb on nci_transceive early error paths", " - nfc: nci: clear NCI_DATA_EXCHANGE before calling completion callback", " - nfc: rawsock: cancel tx_work before socket teardown", " - net: stmmac: Fix error handling in VLAN add and delete paths", " - net: ethernet: mtk_eth_soc: Reset prog ptr to old_prog in case of error", " in mtk_xdp_setup()", " - net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled", " - net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled", " - net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop", " - net/sched: act_ife: Fix metalist update behavior", " - xdp: use modulo operation to calculate XDP frag tailroom", " - xsk: introduce helper to determine rxq->frag_size", " - i40e: fix registering XDP RxQ info", " - i40e: use xdp.frame_sz as XDP RxQ info frag_size", " - xdp: produce a warning when calculated tailroom is negative", " - selftest/arm64: Fix sve2p1_sigill() to hwcap test", " - tracing: Add NULL pointer check to trigger_data_free()", " - net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared", " blocks", " - net: tcp: accept old ack during closing", " - scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT", " - ACPI: PM: Save NVS memory on Lenovo G70-35", " - scsi: mpi3mr: Add NULL checks when resetting request and reply queues", " - unshare: fix unshare_fs() handling", " - wifi: mac80211: set default WMM parameters on all links", " - ACPI: OSI: Add DMI quirk for Acer Aspire One D255", " - scsi: ses: Fix devices attaching to different hosts", " - ASoC: amd: yc: Add ASUS EXPERTBOOK BM1503CDA to quirk table", " - ASoC: cs42l43: Report insert for exotic peripherals", " - scsi: ufs: core: Fix possible NULL pointer dereference in", " ufshcd_add_command_trace()", " - scsi: ufs: core: Fix shift out of bounds when MAXQ=32", " - ALSA: usb-audio: Avoid implicit feedback mode on DIYINHK USB Audio 2.0", " - ALSA: usb-audio: Check max frame size for implicit feedback mode, too", " - powerpc/uaccess: Fix inline assembly for clang build on PPC32", " - remoteproc: sysmon: Correct subsys_name_len type in QMI request", " - powerpc: 83xx: km83xx: Fix keymile vendor prefix", " - xprtrdma: Decrement re_receiving on the early exit paths", " - net: dsa: realtek: rtl8365mb: remove ifOutDiscards from rx_packets", " - drm/msm/dsi: Document DSC related pclk_rate and hdisplay calculations", " - drm/msm/dsi: fix pclk rate calculation for bonded dsi", " - bonding: handle BOND_LINK_FAIL, BOND_LINK_BACK as valid link states", " - net/mlx5: IFC updates for disabled host PF", " - net/mlx5: Query to see if host PF is disabled", " - net/mlx5: Fix deadlock between devlink lock and esw->wq", " - net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery", " - net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL", " slave xmit", " - ASoC: soc-core: drop delayed_work_pending() check before flush", " - ASoC: soc-core: flush delayed work before removing DAIs and widgets", " - ASoC: simple-card-utils: use __free(device_node) for device node", " - ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays", " - net: sfp: improve Huawei MA5671a fixup", " - serial: caif: hold tty->link reference in ldisc_open and ser_release", " - mctp: i2c: fix skb memory leak in receive path", " - can: hi311x: hi3110_open(): add check for hi3110_power_enable() return", " value", " - mctp: route: hold key->lock in mctp_flow_prepare_output()", " - amd-xgbe: fix link status handling in xgbe_rx_adaptation", " - amd-xgbe: prevent CRC errors during RX adaptation with AN disabled", " - netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()", " - netfilter: x_tables: guard option walkers against 1-byte tail reads", " - netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path", " - netfilter: nfnetlink_cthelper: fix OOB read in", " nfnl_cthelper_dump_table()", " - regulator: pca9450: Make IRQ optional", " - regulator: pca9450: Correct interrupt type", " - sched: idle: Make skipping governor callbacks more consistent", " - nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set", " - nvme-pci: Fix race bug in nvme_poll_irqdisable()", " - i40e: fix src IP mask checks and memcpy argument names in cloud filter", " - e1000/e1000e: Fix leak in DMA error cleanup", " - ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()", " - ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock", " acquisition", " - ASoC: detect empty DMI strings", " - net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled", " - octeontx2-af: devlink: fix NIX RAS reporter recovery condition", " - octeontx2-af: devlink: fix NIX RAS reporter to use RAS interrupt status", " - usb: gadget: f_mass_storage: Fix potential integer overflow in", " check_command_size_in_blocks()", " - cgroup: fix race between task migration and iteration", " - ALSA: pcm: fix use-after-free on linked stream runtime in", " snd_pcm_drain()", " - ALSA: usb-audio: Check endpoint numbers at parsing Scarlett2 mixer", " interfaces", " - net: usb: lan78xx: fix silent drop of packets with checksum errors", " - net: usb: lan78xx: fix TX byte statistics for small packets", " - net: usb: lan78xx: skip LTM configuration for LAN7850", " - ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK PM1503CDA", " - KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel", " APIC", " - USB: add QUIRK_NO_BOS for video capture several devices", " - usb/core/quirks: Add Huawei ME906S-device to wakeup quirk", " - USB: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed", " - usb: xhci: Fix memory leak in xhci_disable_slot()", " - usb: xhci: Prevent interrupt storm on host controller error (HCE)", " - usb: yurex: fix race in probe", " - usb: dwc3: pci: add support for the Intel Nova Lake -H", " - usb: misc: uss720: properly clean up reference in uss720_probe()", " - usb: core: don't power off roothub PHYs if phy_set_mode() fails", " - usb: cdc-acm: Restore CAP_BRK functionnality to CH343", " - usb: roles: get usb role switch from parent only for usb-b-connector", " - USB: usbcore: Introduce usb_bulk_msg_killable()", " - USB: usbtmc: Use usb_bulk_msg_killable() with user-specified timeouts", " - USB: core: Limit the length of unkillable synchronous timeouts", " - usb: class: cdc-wdm: fix reordering issue in read code path", " - usb: renesas_usbhs: fix use-after-free in ISR during device removal", " - usb: mdc800: handle signal and read racing", " - usb: image: mdc800: kill download URB on timeout", " - mm/tracing: rss_stat: ensure curr is false from kthread context", " - mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()", " - mm/kfence: disable KFENCE upon KASAN HW tags enablement", " - mmc: core: Avoid bitfield RMW for claim/retune flags", " - ASoC: qcom: qdsp6: Fix q6apm remove ordering during ADSP stop and start", " - tipc: fix divide-by-zero in tipc_sk_filter_connect()", " - kprobes: avoid crash when rmmod/insmod after ftrace killed", " - libceph: reject preamble if control segment is empty", " - libceph: Use u32 for non-negative values in ceph_monmap_decode()", " - libceph: admit message frames only in CEPH_CON_S_OPEN state", " - ceph: fix i_nlink underrun during async unlink", " - ceph: fix memory leaks in ceph_mdsc_build_path()", " - time/jiffies: Mark jiffies_64_to_clock_t() notrace", " - i3c: dw-i3c-master: Set SIR_REJECT in DAT on device attach and reattach", " - scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend", " - scsi: hisi_sas: Add time interval between two H2D FIS following soft", " reset spec", " - scsi: hisi_sas: Use macro instead of magic number", " - scsi: hisi_sas: Fix NULL pointer exception during user_scan()", " - Revert \"tcpm: allow looking for role_sw device in the main node\"", " - drm/bridge: samsung-dsim: Fix memory leak in error path", " - drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used", " - device property: Allow secondary lookup in fwnode_get_next_child_node()", " - irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS", " supports", " - ice: reintroduce retry mechanism for indirect AQ", " - ixgbevf: fix link setup issue", " - staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()", " - staging: rtl8723bs: fix potential out-of-bounds read in", " rtw_restruct_wmm_ie", " - media: dvb-net: fix OOB access in ULE extension header tables", " - net: mana: Ring doorbell at 4 CQ wraparounds", " - ice: fix retry for AQ command 0x06EE", " - tracing: Fix syscall events activation by ensuring refcount hits zero", " - batman-adv: Avoid double-rtnl_lock ELP metric worker", " - parisc: Increase initial mapping to 64 MB with KALLSYMS", " - nouveau/dpcd: return EBUSY for aux xfer if the device is asleep", " - arm64: mm: Add PTE_DIRTY back to PAGE_KERNEL* to fix kexec/hibernation", " - hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read", " - parisc: Fix initial page table creation for boot", " - parisc: Check kernel mapping earlier at bootup", " - pmdomain: bcm: bcm2835-power: Fix broken reset status read", " - net: ncsi: fix skb leak in error paths", " - net: ethernet: arc: emac: quiesce interrupts before requesting IRQ", " - net: dsa: microchip: Fix error path in PTP IRQ setup", " - drm/amdgpu: Fix use-after-free race in VM acquire", " - drm/amd: Set num IP blocks to 0 if discovery fails", " - drm/bridge: ti-sn65dsi83: fix CHA_DSI_CLK_RANGE rounding", " - drm/i915: Fix potential overflow of shmem scatterlist length", " - tracing: Fix trace_buf_size= cmdline parameter with sizes >= 2G", " - cifs: make default value of retrans as zero", " - xfs: fix undersized l_iclog_roundoff values", " - s390/dasd: Move quiesce state with pprc swap", " - s390/dasd: Copy detected format information to secondary device", " - lib/bootconfig: fix off-by-one in xbc_verify_tree() unclosed brace error", " - scsi: core: Fix error handling for scsi_alloc_sdev()", " - x86/apic: Disable x2apic on resume if the kernel expects so", " - lib/bootconfig: fix snprintf truncation check in", " xbc_node_compose_key_after()", " - lib/bootconfig: check bounds before writing in __xbc_open_brace()", " - smb: client: fix atomic open with O_DIRECT & O_SYNC", " - smb: client: fix in-place encryption corruption in SMB2_write()", " - smb: client: fix iface port assignment in parse_server_interfaces", " - btrfs: abort transaction on failure to update root in the received", " subvol ioctl", " - iio: dac: ds4424: reject -128 RAW value", " - iio: frequency: adf4377: Fix duplicated soft reset mask", " - iio: chemical: sps30_serial: fix buffer size in sps30_serial_read_meas()", " - iio: chemical: sps30_i2c: fix buffer size in sps30_i2c_read_meas()", " - iio: potentiometer: mcp4131: fix double application of wiper shift", " - iio: chemical: bme680: Fix measurement wait duration calculation", " - iio: buffer: Fix wait_queue not being removed", " - iio: gyro: mpu3050-core: fix pm_runtime error handling", " - iio: gyro: mpu3050-i2c: fix pm_runtime error handling", " - iio: imu: inv_icm42600: fix odr switch to the same value", " - i3c: mipi-i3c-hci: Use ETIMEDOUT instead of ETIME for timeout errors", " - i3c: mipi-i3c-hci: Restart DMA ring correctly after dequeue abort", " - i3c: mipi-i3c-hci: Add missing TID field to no-op command descriptor", " - drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD", " - gve: defer interrupt enabling until NAPI registration", " - ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths", " - wifi: libertas: fix use-after-free in lbs_free_adapter()", " - platform/x86: hp-bioscfg: Support allocations of larger data", " - x86/sev: Allow IBPB-on-Entry feature for SNP guests", " - gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for", " QPL", " - net: phy: register phy led_triggers during probe to avoid AB-BA deadlock", " - drm/amd/display: Use GFP_ATOMIC in dc_create_stream_for_sink", " - mptcp: pm: avoid sending RM_ADDR over same subflow", " - mptcp: pm: in-kernel: always mark signal+subflow endp as used", " - selftests: mptcp: add a check for 'add_addr_accepted'", " - selftests: mptcp: join: check RM_ADDR not sent over same subflow", " - kbuild: Leave objtool binary around with 'make clean'", " - net/sched: act_gate: snapshot parameters with RCU on replace", " - can: gs_usb: gs_can_open(): always configure bitrates before starting", " device", " - usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling", " - KVM: SVM: Limit AVIC physical max index based on configured max_vcpu_ids", " - KVM: SVM: Add a helper to look up the max physical ID for AVIC", " - KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated", " - mm/kfence: fix KASAN hardware tag faults during late enablement", " - iomap: reject delalloc mappings during writeback", " - ksmbd: Don't log keys in SMB3 signing and encryption key generation", " - drm/msm: Fix dma_free_attrs() buffer size", " - drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output", " - net: macb: Shuffle the tx ring before enabling tx", " - cifs: open files should not hold ref on superblock", " - crypto: atmel-sha204a - Fix OOM ->tfm_count leak", " - xfs: fix integer overflow in bmap intent sort comparator", " - xfs: ensure dquot item is deleted from AIL only after log shutdown", " - smb: client: Compare MACs in constant time", " - ksmbd: Compare MACs in constant time", " - f2fs: fix to avoid migrating empty section", " - ext4: fix dirtyclusters double decrement on fs shutdown", " - btrfs: always fallback to buffered write if the inode requires checksum", " - net: stmmac: dwmac-loongson: Set clk_csr_i to 100-150MHz", " - arm64: mm: Don't remap pgtables per-cont(pte|pmd) block", " - arm64: mm: Batch dsb and isb when populating pgtables", " - arm64: mm: Don't remap pgtables for allocate vs populate", " - dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()", " - ext4: always allocate blocks only from groups inode can use", " - rxrpc: Fix recvmsg() unconditional requeue", " - dm-verity: disable recursive forward error correction", " - ipv6: use RCU in ip6_xmit()", " - rxrpc: Fix data-race warning and potential load/store tearing", " - btrfs: do not strictly require dirty metadata threshold for metadata", " writepages", " - riscv: Sanitize syscall table indexing under speculation", " - dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()", " - tracing: Add recursion protection in kernel stack trace recording", " - net: add support for segmenting TCP fraglist GSO packets", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", " - net: fix segmentation of forwarding fraglist GRO", " - net: dsa: properly keep track of conduit reference", " - drm/amd/display: Add pixel_clock to amd_pp_display_configuration", " - drm/amd/pm: Use pm_display_cfg in legacy DPM (v2)", " - drm/amdgpu: Add basic validation for RAS header", " - drm/exynos: vidi: use priv->vidi_dev for ctx lookup in", " vidi_connection_ioctl()", " - drm/exynos: vidi: fix to avoid directly dereferencing user pointer", " - drm/exynos: vidi: use ctx->lock to protect struct vidi_context member", " variables related to memory alloc/free", " - x86/uprobes: Fix XOL allocation failure for 32-bit tasks", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - binfmt_misc: restore write access before closing files opened by", " open_exec()", " - net: stmmac: remove support for lpi_intr_o", " - mptcp: pm: in-kernel: always set ID as avail when rm endp", " - s390/xor: Fix xor_xc_2() inline assembly constraints", " - s390/stackleak: Fix __stackleak_poison() inline assembly constraint", " - s390/zcrypt: Enable AUTOSEL_DOM for CCA serialnr sysfs attribute", " - mm/mempolicy: fix wrong mmap_read_unlock() in migrate_to_node()", " - io_uring/kbuf: check if target buffer list is still legacy on recycle", " - NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd", " - sunrpc: fix cache_request leak in cache_release", " - nvdimm/bus: Fix potential use after free in asynchronous initialization", " - LoongArch: Give more information if kmem access failed", " - NFC: nxp-nci: allow GPIOs to sleep", " - net: macb: fix use-after-free access to PTP clock", " - parisc: Flush correct cache in cacheflush() syscall", " - Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()", " - Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access", " - smb: client: fix krb5 mount with username option", " - ksmbd: unset conn->binding on failed binding request", " - kprobes: Remove unneeded goto", " - kprobes: Remove unneeded warnings from __arm_kprobe_ftrace()", " - btrfs: fix transaction abort when snapshotting received subvolumes", " - btrfs: fix transaction abort on set received ioctl due to item overflow", " - btrfs: fix transaction abort on file creation due to name hash collision", " - iio: light: bh1780: fix PM runtime leak on error path", " - batman-adv: avoid OGM aggregation when skb tailroom is insufficient", " - net: macb: queue tie-off or disable during WOL suspend", " - net: macb: Introduce gem_init_rx_ring()", " - net: macb: Reinitialize tx/rx queue pointer registers and rx ring during", " resume", " - mmc: sdhci-pci-gli: fix GL9750 DMA write corruption", " - mmc: sdhci: fix timing selection for 1-bit bus width", " - pmdomain: bcm: bcm2835-power: Increase ASB control timeout", " - spi: fix use-after-free on controller registration failure", " - spi: fix statistics allocation", " - mtd: rawnand: pl353: make sure optimal timings are applied", " - mtd: rawnand: cadence: Fix error check for dma_alloc_coherent() in", " cadence_nand_init()", " - mtd: Avoid boot crash in RedBoot partition table parser", " - iommu/vt-d: Fix intel iommu iotlb sync hardlockup and retry", " - serial: 8250_pci: add support for the AX99100", " - serial: 8250: Fix TX deadlock when using DMA", " - serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART", " BUSY", " - serial: uartlite: fix PM runtime usage count underflow on probe", " - drm/amdgpu/gmc9.0: add bounds checking for cid", " - drm/amdgpu/mmhub2.0: add bounds checking for cid", " - drm/amdgpu/mmhub2.3: add bounds checking for cid", " - drm/amdgpu/mmhub3.0.1: add bounds checking for cid", " - drm/amdgpu/mmhub3.0.2: add bounds checking for cid", " - drm/amdgpu/mmhub3.0: add bounds checking for cid", " - drm/radeon: apply state adjust rules to some additional HAINAN vairants", " - drm/amdgpu: apply state adjust rules to some additional HAINAN vairants", " - drm/amd/display: Wrap dcn32_override_min_req_memclk() in DC_FP_{START,", " END}", " - btrfs: log new dentries when logging parent dir of a conflicting inode", " - btrfs: tree-checker: fix misleading root drop_level error message", " - cache: ax45mp: Fix device node reference leak in ax45mp_cache_init()", " - soc: fsl: qbman: fix race condition in qman_destroy_fq", " - wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.", " - wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down", " - firmware: arm_scpi: Fix device_node reference leak in probe path", " - Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU", " - Bluetooth: LE L2CAP: Disconnect if sum of payload sizes exceed SDU", " - Bluetooth: SMP: make SM/PER/KDU/BI-04-C happy", " - Bluetooth: ISO: Fix defer tests being unstable", " - Bluetooth: hci_sync: Fix hci_le_create_conn_sync", " - Bluetooth: HIDP: Fix possible UAF", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user", " - Bluetooth: qca: fix ROM version reading on WCN3998 chips", " - net/rose: fix NULL pointer dereference in rose_transmit_link on", " reconnect", " - mpls: add missing unregister_netdevice_notifier to mpls_init", " - netfilter: ctnetlink: remove refcounting in expectation dumpers", " - netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()", " - netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in", " sip_help_tcp()", " - netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case", " - netfilter: nft_ct: drop pending enqueued packets on removal", " - netfilter: xt_CT: drop pending enqueued packets on template removal", " - netfilter: xt_time: use unsigned int for monthday bit shift", " - net: bcmgenet: increase WoL poll timeout", " - net: mana: fix use-after-free in mana_hwc_destroy_channel() by", " reordering teardown", " - sched: idle: Consolidate the handling of two special cases", " - PM: runtime: Fix a race condition related to device removal", " - net/sched: teql: Fix double-free in teql_master_xmit", " - net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check", " - net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check", " - clsact: Fix use-after-free in init/destroy rollback asymmetry", " - net: usb: aqc111: Do not perform PM inside suspend callback", " - igc: fix missing update of skb->tail in igc_xmit_frame()", " - iavf: fix VLAN filter lost on add/delete race", " - wifi: mac80211: fix NULL deref in mesh_matches_local()", " - wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough", " headroom", " - ACPI: processor: Fix previous acpi_processor_errata_piix4() fix", " - net: macb: fix uninitialized rx_fs_lock", " - net/mlx5: qos: Restrict RTNL area to avoid a lock cycle", " - net/mlx5e: Prevent concurrent access to IPSec ASO context", " - net/mlx5e: Fix race condition during IPSec ESN update", " - udp_tunnel: fix NULL deref caused by udp_sock_create6 when CONFIG_IPV6=n", " - net: bonding: fix NULL deref in bond_debug_rlb_hash_show", " - netfilter: bpf: defer hook memory release until rcu readers are done", " - nfnetlink_osf: validate individual option lengths in fingerprints", " - net: mvpp2: guard flow control update with global_tx_fc in buffer", " switching", " - net: dsa: bcm_sf2: fix missing clk_disable_unprepare() in error paths", " - icmp: fix NULL pointer dereference in icmp_tag_validation()", " - hwmon: (pmbus/mp2975) Add error check for pmbus_read_word_data() return", " value", " - hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit()", " - Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ", " - USB: serial: f81232: fix incomplete serial port generation", " - i2c: fsi: Fix a potential leak in fsi_i2c_probe()", " - i2c: pxa: defer reset on Armada 3700 when recovery is used", " - x86/platform/uv: Handle deconfigured sockets", " - i2c: cp2615: fix serial string NULL-deref at probe", " - mtd: rawnand: serialize lock/unlock against other NAND operations", " - mtd: rawnand: brcmnand: skip DMA during panic write", " - drm/amd/display: Fix DisplayID not-found handling in", " parse_edid_displayid_vrr()", " - drm/i915/gt: Check set_default_submission() before deferencing", " - lib/bootconfig: check xbc_init_node() return in override path", " - tools/bootconfig: fix fd leak in load_xbc_file() on fstat failure", " - xen/privcmd: restrict usage in unprivileged domU", " - xen/privcmd: add boot control for restricted usage in domU", " - cgroup/cpuset: Fix incorrect use of cpuset_update_tasks_cpumask() in", " update_cpumasks_hier()", " - s390/idle: Fix cpu idle exit cpu time accounting", " - s390/vtime: Fix virtual timer forwarding", " - PCI: endpoint: Introduce pci_epc_function_is_valid()", " - PCI: endpoint: Introduce pci_epc_mem_map()/unmap()", " - PCI: dwc: endpoint: Implement the pci_epc_ops::align_addr() operation", " - PCI: dwc: ep: Use align addr function for", " dw_pcie_ep_raise_{msi,msix}_irq()", " - PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry", " - drm/amdgpu: Replace kzalloc + copy_from_user with memdup_user", " - drm/amdgpu: Fix locking bugs in error paths", " - btrfs: print correct subvol num if active swapfile prevents deletion", " - bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic", " tearing", " - x86/acpi/boot: Correct acpi_is_processor_usable() check again", " - PCI: dw-rockchip: Don't wait for link since we can detect Link Up", " - Revert \"PCI: dw-rockchip: Don't wait for link since we can detect Link", " Up\"", " - ata: libata-scsi: Refactor ata_scsi_simulate()", " - ata: libata-scsi: Refactor ata_scsiop_read_cap()", " - ata: libata-scsi: Refactor ata_scsiop_maint_in()", " - ata: libata-scsi: Document all VPD page inquiry actors", " - ata: libata-scsi: Remove struct ata_scsi_args", " - ata: libata: Remove ATA_DFLAG_ZAC device flag", " - ata: libata: Introduce ata_port_eh_scheduled()", " - ata: libata-scsi: avoid Non-NCQ command starvation", " - workqueue: Add system_percpu_wq and system_dfl_wq", " - Input: synaptics_i2c - replace use of system_wq with system_dfl_wq", " - Input: synaptics_i2c - guard polling restart in resume", " - arm64: dts: rockchip: Fix rk3588 PCIe range mappings", " - ima: kexec: silence RCU list traversal warning", " - ima: rename variable the seq_file \"file\" to \"ima_kexec_file\"", " - ima: define and call ima_alloc_kexec_file_buf()", " - kexec: define functions to map and unmap segments", " - ima: kexec: define functions to copy IMA log at soft boot", " - ima: verify the previous kernel's IMA buffer lies in addressable RAM", " - of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range()", " - drm/exynos/vidi: Remove redundant error handling in vidi_get_modes()", " - btrfs: zoned: fix alloc_offset calculation for partly conventional block", " groups", " - btrfs: zoned: fixup last alloc pointer after extent removal for RAID1", " - btrfs: zoned: fixup last alloc pointer after extent removal for DUP", " - btrfs: zoned: fix stripe width calculation", " - btrfs: define the AUTO_KFREE/AUTO_KVFREE helper macros", " - btrfs: zoned: fixup last alloc pointer after extent removal for RAID0/10", " - ksmbd: check return value of xa_store() in krb5_authenticate", " - ksmbd: add chann_lock to protect ksmbd_chann_list xarray", " - ALSA: hda/realtek: Add quirk for Gigabyte G5 KF5 (2023)", " - ALSA: hda/realtek: Implement sound init sequence for Samsung Galaxy", " Book3 Pro 360", " - ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book3 Ultra", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: hda/realtek: Add quirk for Samsung Galaxy Book3 Pro 360 (NP965QFG)", " - ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing", " with clang < 18", " - nvme: fix admin queue leak on controller reset", " - HID: multitouch: add quirks for Lenovo Yoga Book 9i", " - HID: multitouch: new class MT_CLS_EGALAX_P80H84", " - idpf: change IRQ naming to match netdev and ethtool queue numbering", " - i40e: Fix preempt count leak in napi poll tracepoint", " - drm/xe: Do not preempt fence signaling CS instructions", " - wifi: mt76: mt7925: Fix possible oob access in", " mt7925_mac_write_txwi_80211()", " - i2c: i801: Revert \"i2c: i801: replace acpi_lock with I2C bus lock\"", " - drm/xe/reg_sr: Fix leak on xa_store failure", " - net_sched: sch_fq: clear q->band_pkt_count[] in fq_reset()", " - ata: libata-core: fix cancellation of a port deferred qc work", " - ata: libata-eh: correctly handle deferred qc timeouts", " - ata: libata: cancel pending work after clearing deferred_qc", " - ata: libata-eh: Fix detection of deferred qc timeouts", " - Upstream stable to v6.6.129, v6.6.130, v6.12.76, v6.12.77", "", " * Noble update: upstream stable patchset 2026-05-28 (LP: #2154496) //", " CVE-2026-43067", " - ext4: handle wraparound when searching for blocks for indirect mapped", " blocks", "", " * Noble update: upstream stable patchset 2026-05-28 (LP: #2154496) //", " CVE-2025-39930", " - ASoC: simple-card-utils: Don't use __free(device_node) at", " graph_util_parse_dai()", "", " * CVE-2026-46244", " - netfilter: nft_inner: Fix IPv6 inner_thoff desync", "", " * CVE-2026-43185", " - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()", "", " * CVE-2026-46289", " - lib/scatterlist: fix length calculations in extract_kvec_to_sg", "", " * CVE-2026-46119", " - libceph: Fix slab-out-of-bounds access in auth message processing", "", " * CVE-2026-46135", " - nvmet-tcp: fix race between ICReq handling and queue teardown", "", " * CVE-2026-46185", " - smb/client: fix out-of-bounds read in symlink_data()", "", " * CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", "", " * CVE-2026-46115", " - block: add pgmap check to biovec_phys_mergeable", "", " * CVE-2026-43501", " - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows", "", " * CVE-2026-45988", " - rxrpc: Fix re-decryption of RESPONSE packets", "", " * CVE-2026-46043", " - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv", "", " * CVE-2026-43493", " - crypto: pcrypt - Fix handling of MAY_BACKLOG requests", "", " * CVE-2026-43071", " - dcache: Limit the minimal number of bucket to two", "", " * CVE-2026-31685", " - netfilter: ip6t_eui64: reject invalid MAC header for all packets", "", " * CVE-2026-43117", " - btrfs: tracepoints: get correct superblock from dentry in event", " btrfs_sync_file()", "", " * CVE-2026-43114", " - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on", " expiry", "", " * CVE-2026-31607", " - usbip: validate number_of_packets in usbip_pack_ret_submit()", "", " * CVE-2026-31659", " - batman-adv: reject oversized global TT response buffers", "", " * CVE-2026-31649", " - net: stmmac: fix integer underflow in chain mode", "", " * CVE-2026-31657", " - batman-adv: hold claim backbone gateways by reference", "", " * CVE-2026-31637", " - rxrpc: reject undecryptable rxkad response tickets", "", " * CVE-2026-31669", " - mptcp: fix slab-use-after-free in __inet_lookup_established", "", " * CVE-2026-31668", " - seg6: separate dst_cache for input and output paths in seg6 lwtunnel", "", " * CVE-2026-43011", " - net/x25: Fix potential double free of skb", "", " * CVE-2026-43037", " - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()", "", " * CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", "", " * CVE-2026-43038", " - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()", "", " * CVE-2026-31682", " - bridge: br_nd_send: linearize skb before parsing ND options", "", " * CVE-2026-31436", " - dmaengine: idxd: fix possible wrong descriptor completion in", " llist_abort_desc()", "", " * CVE-2026-43384", " - net/tcp-ao: Fix MAC comparison to be constant-time", "", " * CVE-2026-31448", " - ext4: get rid of ppath in ext4_find_extent()", " - ext4: get rid of ppath in ext4_ext_create_new_leaf()", " - ext4: get rid of ppath in ext4_ext_insert_extent()", " - ext4: avoid infinite loops caused by residual data", "", " * CVE-2026-31478", " - ksmbd: replace hardcoded hdr2_len with offsetof() in", " smb2_calc_max_out_buf_len()", "", " * CVE-2026-23428", " - ksmbd: fix use-after-free of share_conf in compound request", "", " * CVE-2026-23450", " - net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()", "", " * CVE-2026-23455", " - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()", "", " * CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", "", " * CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", "", " * CVE-2026-43378", " - smb: server: fix use-after-free in smb2_open()", "", " * CVE-2026-46243", " - smb: client: reject userspace cifs.spnego descriptions", "", " * CVE-2026-43414", " - scsi: qla2xxx: Completely fix fcport double free", "", " * CVE-2026-43407", " - libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()", "", " * CVE-2026-43406", " - libceph: prevent potential out-of-bounds reads in", " process_message_header()", "" ], "package": "linux", "version": "6.8.0-136.136", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2158930, 2158377, 2137199, 2131077, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156956, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156619, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156549, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156373, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2156149, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155958, 2155660, 2154496, 2154496, 2154496 ], "author": "Mehmet Basaran ", "date": "Wed, 01 Jul 2026 22:48:01 +0300" } ], "notes": "linux-modules-6.8.0-136-generic version '6.8.0-136.136' (source package linux version '6.8.0-136.136') was added. linux-modules-6.8.0-136-generic version '6.8.0-136.136' has the same source package name, linux, as removed package linux-modules-6.8.0-134-generic. As such we can use the source package version of the removed package, '6.8.0-134.134', 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-134-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-134.134", "version": "6.8.0-134.134" }, "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-134-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-134.134", "version": "6.8.0-134.134" }, "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 release image serial 20260716 to 20260717", "from_series": "noble", "to_series": "noble", "from_serial": "20260716", "to_serial": "20260717", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }