{
"summary": {
"snap": {
"added": [],
"removed": [],
"diff": []
},
"deb": {
"added": [
"linux-headers-6.17.0-40",
"linux-headers-6.17.0-40-generic",
"linux-image-6.17.0-40-generic",
"linux-modules-6.17.0-40-generic",
"linux-tools-6.17.0-40",
"linux-tools-6.17.0-40-generic"
],
"removed": [
"linux-headers-6.17.0-35",
"linux-headers-6.17.0-35-generic",
"linux-image-6.17.0-35-generic",
"linux-modules-6.17.0-35-generic",
"linux-tools-6.17.0-35",
"linux-tools-6.17.0-35-generic"
],
"diff": [
"bpftool",
"curl",
"iproute2",
"libcurl3t64-gnutls",
"libcurl4t64",
"libncurses6",
"libncursesw6",
"libnghttp2-14",
"libnss3",
"libperl5.40",
"libsqlite3-0",
"libssh2-1t64",
"libtinfo6",
"libxml2-16",
"linux-headers-generic",
"linux-headers-virtual",
"linux-image-virtual",
"linux-libc-dev",
"linux-perf",
"linux-tools-common",
"linux-virtual",
"ncurses-base",
"ncurses-bin",
"ncurses-term",
"perl",
"perl-base",
"perl-modules-5.40",
"vim",
"vim-common",
"vim-runtime",
"vim-tiny",
"xxd"
]
}
},
"diff": {
"deb": [
{
"name": "bpftool",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "7.7.0+6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "7.7.0+6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "curl",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.4",
"version": "8.14.1-2ubuntu1.4"
},
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Connection reuse for starttls protocols.",
" - debian/patches/CVE-2026-8286.patch: When a connection is tested for",
" reuse in a transfer that may upgrade to TLS (commonly via STARTTLS),",
" the SSL configuration must match the existing connection in lib/url.c",
" - CVE-2026-8286",
" * SECURITY UPDATE: Connection reuse in SASL.",
" - debian/patches/CVE-2026-8458.patch: Fix erroneous connection reuse in",
" in lib/curl_sasl.c, lib/http_negotiate.c, lib/http_ntlm.c, lib/imap.c,",
" lib/openldap.c, and lib/pop3.c",
" - CVE-2026-8458",
" * SECURITY UPDATE: Cookie injection in is_public_suffix.",
" - debian/patches/CVE-2026-8924.patch: Trim trailing dots when checking",
" PSL in lib/cookie.c.",
" - CVE-2026-8924",
" * SECURITY UPDATE: Double-free in gsasl.",
" - debian/patches/CVE-2026-8925.patch: Require libgasl 1.6.0 to handle",
" NULL argument in lib/vauth/gsasl.c.",
" - CVE-2026-8925",
" * SECURITY UPDATE: Information disclosure in netrc.",
" - debian/patches/CVE-2026-8926.patch: Do not return a password from",
" parsenetrc() when the requested login did not match the credentials",
" found for the matched machine in lib/netrc.c.",
" - CVE-2026-8926",
" * SECURITY UPDATE: Information disclosure in libcurl",
" - debian/patches/CVE-2026-8927.patch: Detect if proxy is not the same as",
" previous and flush state in lib/url.c and lib/urldata.h.",
" - debian/patches/CVE-2026-9079.patch: Verify NULLed proxy credentials",
" in lib/setopt.c.",
" - debian/patches/CVE-2026-9545.patch: Hard fail when certificate",
" verification fails in lib/vquic/curl_ngtcp2.c.",
" - CVE-2026-8927",
" - CVE-2026-9079",
" - CVE-2026-9545",
" * SECURITY UPDATE: Use-after-free in curl_easy_parse",
" - debian/patches/CVE-2026-9080.patch: Introduce magic struct field to",
" assert against NULL pointers in lib/multi_ev.c",
" - CVE-2026-9080",
" * SECURITY UPDATE: Man-in-the-middle in libcurl.",
" - debian/patches/CVE-2026-9547.patch: Reject host key mismatches in",
" in lib/vssh/libssh.c",
" - CVE-2026-9547",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Mon, 29 Jun 2026 10:12:37 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "iproute2",
"from_version": {
"source_package_name": "iproute2",
"source_package_version": "6.16.0-1ubuntu2.1",
"version": "6.16.0-1ubuntu2.1"
},
"to_version": {
"source_package_name": "iproute2",
"source_package_version": "6.16.0-1ubuntu2.2",
"version": "6.16.0-1ubuntu2.2"
},
"cves": [],
"launchpad_bugs_fixed": [
2147525
],
"changes": [
{
"cves": [],
"log": [
"",
" * Modify tc/tbf and tc/htb to allow 64 bit burst parameter (LP: #2147525)",
" - /d/p/lp2147525-1-tc-tbf-enable-64-bit-burst.patch",
" - /d/p/lp2147525-2-tc-htb-enable-64-bit-burst.patch",
""
],
"package": "iproute2",
"version": "6.16.0-1ubuntu2.2",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2147525
],
"author": "Ioana Lazea ",
"date": "Fri, 10 Apr 2026 11:00:53 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libcurl3t64-gnutls",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.4",
"version": "8.14.1-2ubuntu1.4"
},
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Connection reuse for starttls protocols.",
" - debian/patches/CVE-2026-8286.patch: When a connection is tested for",
" reuse in a transfer that may upgrade to TLS (commonly via STARTTLS),",
" the SSL configuration must match the existing connection in lib/url.c",
" - CVE-2026-8286",
" * SECURITY UPDATE: Connection reuse in SASL.",
" - debian/patches/CVE-2026-8458.patch: Fix erroneous connection reuse in",
" in lib/curl_sasl.c, lib/http_negotiate.c, lib/http_ntlm.c, lib/imap.c,",
" lib/openldap.c, and lib/pop3.c",
" - CVE-2026-8458",
" * SECURITY UPDATE: Cookie injection in is_public_suffix.",
" - debian/patches/CVE-2026-8924.patch: Trim trailing dots when checking",
" PSL in lib/cookie.c.",
" - CVE-2026-8924",
" * SECURITY UPDATE: Double-free in gsasl.",
" - debian/patches/CVE-2026-8925.patch: Require libgasl 1.6.0 to handle",
" NULL argument in lib/vauth/gsasl.c.",
" - CVE-2026-8925",
" * SECURITY UPDATE: Information disclosure in netrc.",
" - debian/patches/CVE-2026-8926.patch: Do not return a password from",
" parsenetrc() when the requested login did not match the credentials",
" found for the matched machine in lib/netrc.c.",
" - CVE-2026-8926",
" * SECURITY UPDATE: Information disclosure in libcurl",
" - debian/patches/CVE-2026-8927.patch: Detect if proxy is not the same as",
" previous and flush state in lib/url.c and lib/urldata.h.",
" - debian/patches/CVE-2026-9079.patch: Verify NULLed proxy credentials",
" in lib/setopt.c.",
" - debian/patches/CVE-2026-9545.patch: Hard fail when certificate",
" verification fails in lib/vquic/curl_ngtcp2.c.",
" - CVE-2026-8927",
" - CVE-2026-9079",
" - CVE-2026-9545",
" * SECURITY UPDATE: Use-after-free in curl_easy_parse",
" - debian/patches/CVE-2026-9080.patch: Introduce magic struct field to",
" assert against NULL pointers in lib/multi_ev.c",
" - CVE-2026-9080",
" * SECURITY UPDATE: Man-in-the-middle in libcurl.",
" - debian/patches/CVE-2026-9547.patch: Reject host key mismatches in",
" in lib/vssh/libssh.c",
" - CVE-2026-9547",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Mon, 29 Jun 2026 10:12:37 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libcurl4t64",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.4",
"version": "8.14.1-2ubuntu1.4"
},
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-8286",
"url": "https://ubuntu.com/security/CVE-2026-8286",
"cve_description": "A vulnerability exists where a new transfer that uses STARTTLS to upgrade the connection might reuse an existing live connection even though the TLS configuration mismatches so it should not.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8458",
"url": "https://ubuntu.com/security/CVE-2026-8458",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different \"services\". libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8924",
"url": "https://ubuntu.com/security/CVE-2026-8924",
"cve_description": "A flaw in curl's cookie parsing logic allows a malicious HTTP server to set \"super cookies\" that bypass the Public Suffix List check. This enables an attacker-controlled origin to inject cookies that curl will subsequently scope and transmit to unrelated third-party domains.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8925",
"url": "https://ubuntu.com/security/CVE-2026-8925",
"cve_description": "The curl logic that works with SASL authentication could end up cleaning up the GSASL context *twice* without clearing the pointer in between, making it `free()` the same pointer twice.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8926",
"url": "https://ubuntu.com/security/CVE-2026-8926",
"cve_description": "When asking curl to use a `.netrc` file to find credentials and at the same time specifying a URL with a username (without a password), like `https://user@example.com/`, curl could wrongly get and use the password for *another* user set in the `.netrc` file for that host if such a one exists and there is no match for the specified user.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-8927",
"url": "https://ubuntu.com/security/CVE-2026-8927",
"cve_description": "When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against `proxyA` using Digest auth, a subsequent transfer routed through `proxyB` erroneously leaks the `Proxy-Authorization:` header intended solely for `proxyA`.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9079",
"url": "https://ubuntu.com/security/CVE-2026-9079",
"cve_description": "libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent tranfers that should not know nor use them.",
"cve_priority": "medium",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9545",
"url": "https://ubuntu.com/security/CVE-2026-9545",
"cve_description": "In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate. When libcurl returns to the hostname the second time with a cached SSL session (`CURLOPT_SSL_SESSIONID_CACHE` is not disabled) and early data enabled (the `CURLSSLOPT_EARLYDATA` bit is set in`CURLOPT_SSL_OPTIONS`), libcurl might send off the second request's bytes on that new connection *before* enforcing the certificate verification failure. Potentially leaking sensitive information.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9080",
"url": "https://ubuntu.com/security/CVE-2026-9080",
"cve_description": "Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability, where libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
},
{
"cve": "CVE-2026-9547",
"url": "https://ubuntu.com/security/CVE-2026-9547",
"cve_description": "When a libcurl-based application performs transfers via `SCP://` or `SFTP://` and utilizes the `CURLOPT_SSH_KEYFUNCTION` callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the `known_hosts` file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.",
"cve_priority": "low",
"cve_public_date": "2026-06-24 14:00:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Connection reuse for starttls protocols.",
" - debian/patches/CVE-2026-8286.patch: When a connection is tested for",
" reuse in a transfer that may upgrade to TLS (commonly via STARTTLS),",
" the SSL configuration must match the existing connection in lib/url.c",
" - CVE-2026-8286",
" * SECURITY UPDATE: Connection reuse in SASL.",
" - debian/patches/CVE-2026-8458.patch: Fix erroneous connection reuse in",
" in lib/curl_sasl.c, lib/http_negotiate.c, lib/http_ntlm.c, lib/imap.c,",
" lib/openldap.c, and lib/pop3.c",
" - CVE-2026-8458",
" * SECURITY UPDATE: Cookie injection in is_public_suffix.",
" - debian/patches/CVE-2026-8924.patch: Trim trailing dots when checking",
" PSL in lib/cookie.c.",
" - CVE-2026-8924",
" * SECURITY UPDATE: Double-free in gsasl.",
" - debian/patches/CVE-2026-8925.patch: Require libgasl 1.6.0 to handle",
" NULL argument in lib/vauth/gsasl.c.",
" - CVE-2026-8925",
" * SECURITY UPDATE: Information disclosure in netrc.",
" - debian/patches/CVE-2026-8926.patch: Do not return a password from",
" parsenetrc() when the requested login did not match the credentials",
" found for the matched machine in lib/netrc.c.",
" - CVE-2026-8926",
" * SECURITY UPDATE: Information disclosure in libcurl",
" - debian/patches/CVE-2026-8927.patch: Detect if proxy is not the same as",
" previous and flush state in lib/url.c and lib/urldata.h.",
" - debian/patches/CVE-2026-9079.patch: Verify NULLed proxy credentials",
" in lib/setopt.c.",
" - debian/patches/CVE-2026-9545.patch: Hard fail when certificate",
" verification fails in lib/vquic/curl_ngtcp2.c.",
" - CVE-2026-8927",
" - CVE-2026-9079",
" - CVE-2026-9545",
" * SECURITY UPDATE: Use-after-free in curl_easy_parse",
" - debian/patches/CVE-2026-9080.patch: Introduce magic struct field to",
" assert against NULL pointers in lib/multi_ev.c",
" - CVE-2026-9080",
" * SECURITY UPDATE: Man-in-the-middle in libcurl.",
" - debian/patches/CVE-2026-9547.patch: Reject host key mismatches in",
" in lib/vssh/libssh.c",
" - CVE-2026-9547",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Mon, 29 Jun 2026 10:12:37 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libncurses6",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libncursesw6",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libnghttp2-14",
"from_version": {
"source_package_name": "nghttp2",
"source_package_version": "1.64.0-1.1ubuntu1.1",
"version": "1.64.0-1.1ubuntu1.1"
},
"to_version": {
"source_package_name": "nghttp2",
"source_package_version": "1.64.0-1.1ubuntu1.2",
"version": "1.64.0-1.1ubuntu1.2"
},
"cves": [
{
"cve": "CVE-2026-58055",
"url": "https://ubuntu.com/security/CVE-2026-58055",
"cve_description": "nghttp2's nghttpx proxy through 1.69.0 forwards an HTTP/1.1 Upgrade request that also carries a Content-Length header and body onto reusable keep-alive backend connections, re-adding the Upgrade and Connection headers while passing Content-Length verbatim. A backend that resolves the resulting ambiguous message in the attacker's favor enables HTTP request/response smuggling and cross-client response-queue poisoning.",
"cve_priority": "medium",
"cve_public_date": "2026-06-28 02:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-58055",
"url": "https://ubuntu.com/security/CVE-2026-58055",
"cve_description": "nghttp2's nghttpx proxy through 1.69.0 forwards an HTTP/1.1 Upgrade request that also carries a Content-Length header and body onto reusable keep-alive backend connections, re-adding the Upgrade and Connection headers while passing Content-Length verbatim. A backend that resolves the resulting ambiguous message in the attacker's favor enables HTTP request/response smuggling and cross-client response-queue poisoning.",
"cve_priority": "medium",
"cve_public_date": "2026-06-28 02:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: HTTP request/response smuggling issue",
" - debian/patches/CVE-2026-58055.patch: nghttpx: Tighten up CONNECT and HTTP",
" Upgrade handling in src/shrpx_downstream.cc, src/shrpx_downstream.h,",
" src/shrpx_http2_upstream.cc, src/shrpx_http3_upstream.cc,",
" src/shrpx_http_downstream_connection.cc,",
" src/shrpx_http_downstream_connection.h, src/shrpx_https_upstream.cc.",
" - CVE-2026-58055",
""
],
"package": "nghttp2",
"version": "1.64.0-1.1ubuntu1.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Tue, 30 Jun 2026 12:43:31 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libnss3",
"from_version": {
"source_package_name": "nss",
"source_package_version": "2:3.114-1ubuntu0.1",
"version": "2:3.114-1ubuntu0.1"
},
"to_version": {
"source_package_name": "nss",
"source_package_version": "2:3.114-1ubuntu0.2",
"version": "2:3.114-1ubuntu0.2"
},
"cves": [
{
"cve": "CVE-2026-12318",
"url": "https://ubuntu.com/security/CVE-2026-12318",
"cve_description": "Incorrect boundary conditions in the Libraries component in NSS. This vulnerability was fixed in Firefox 152 and Thunderbird 152.",
"cve_priority": "medium",
"cve_public_date": "2026-06-16 13:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-12318",
"url": "https://ubuntu.com/security/CVE-2026-12318",
"cve_description": "Incorrect boundary conditions in the Libraries component in NSS. This vulnerability was fixed in Firefox 152 and Thunderbird 152.",
"cve_priority": "medium",
"cve_public_date": "2026-06-16 13:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: OOB read in pk11uri_ParseAttributes",
" - debian/patches/CVE-2026-12318.patch: improve handling of escape",
" sequences in nss/lib/util/pkcs11uri.c.",
" - CVE-2026-12318",
""
],
"package": "nss",
"version": "2:3.114-1ubuntu0.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Thu, 18 Jun 2026 07:25:28 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libperl5.40",
"from_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6build1",
"version": "5.40.1-6build1"
},
"to_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6ubuntu0.1",
"version": "5.40.1-6ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: path traversal in Archive::Tar symlink/hardlink extraction",
" - debian/patches/CVE-2026-42496.patch: validate symlink and hardlink",
" targets against absolute paths and directory traversal in",
" cpan/Archive-Tar/lib/Archive/Tar.pm",
" - CVE-2026-42496",
" * SECURITY UPDATE: integer overflow in regular expression compiler",
" - debian/patches/CVE-2026-8376_1.patch: add test cases for heap buffer",
" overflow via quantified fixed-string regex in t/re/pat_psycho.t",
" - debian/patches/CVE-2026-8376_2.patch: add overflow check before",
" fixed-string buffer allocation in regcomp.c / regcomp_study.c",
" - CVE-2026-8376",
" * debian/rules: temporarily disable flaky op/magic.t test during build",
" in questing environment to allow security updates to proceed",
""
],
"package": "perl",
"version": "5.40.1-6ubuntu0.1",
"urgency": "high",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Chrisa Oikonomou ",
"date": "Fri, 12 Jun 2026 16:42:19 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libsqlite3-0",
"from_version": {
"source_package_name": "sqlite3",
"source_package_version": "3.46.1-8",
"version": "3.46.1-8"
},
"to_version": {
"source_package_name": "sqlite3",
"source_package_version": "3.46.1-8ubuntu0.1",
"version": "3.46.1-8ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2026-11822",
"url": "https://ubuntu.com/security/CVE-2026-11822",
"cve_description": "SQLite before 3.53.2 contains memory corruption vulnerabilities in the FTS5 full-text search extension that allow attackers to cause process crashes, memory exhaustion, or arbitrary code execution by supplying a crafted database with malformed FTS5 page data. Attackers can trigger an out-of-bounds read in fts5LeafSeek() via an attacker-controlled loop bound and a heap buffer overflow write in fts5ChunkIterate() through a crafted continuation page causing an integer underflow, exploitable when an FTS5 MATCH query is executed against the malicious database.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 20:16:00 UTC"
},
{
"cve": "CVE-2026-11824",
"url": "https://ubuntu.com/security/CVE-2026-11824",
"cve_description": "SQLite before 3.53.2 contains a heap-based buffer overflow vulnerability in the FTS5 full-text search extension that allows attackers to cause a crash or execute arbitrary code by supplying a crafted database with malicious continuation page metadata specifying a szLeaf value smaller than 4. Attackers can trigger an integer underflow in fts5ChunkIterate() causing an inflated remaining byte count during FTS5 MATCH query processing, leading to a heap buffer overflow of attacker-controlled data in applications compiled with SQLITE_ENABLE_FTS5.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 20:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-11822",
"url": "https://ubuntu.com/security/CVE-2026-11822",
"cve_description": "SQLite before 3.53.2 contains memory corruption vulnerabilities in the FTS5 full-text search extension that allow attackers to cause process crashes, memory exhaustion, or arbitrary code execution by supplying a crafted database with malformed FTS5 page data. Attackers can trigger an out-of-bounds read in fts5LeafSeek() via an attacker-controlled loop bound and a heap buffer overflow write in fts5ChunkIterate() through a crafted continuation page causing an integer underflow, exploitable when an FTS5 MATCH query is executed against the malicious database.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 20:16:00 UTC"
},
{
"cve": "CVE-2026-11824",
"url": "https://ubuntu.com/security/CVE-2026-11824",
"cve_description": "SQLite before 3.53.2 contains a heap-based buffer overflow vulnerability in the FTS5 full-text search extension that allows attackers to cause a crash or execute arbitrary code by supplying a crafted database with malicious continuation page metadata specifying a szLeaf value smaller than 4. Attackers can trigger an integer underflow in fts5ChunkIterate() causing an inflated remaining byte count during FTS5 MATCH query processing, leading to a heap buffer overflow of attacker-controlled data in applications compiled with SQLITE_ENABLE_FTS5.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 20:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: security issues in FTS5 full-text search",
" - debian/patches/CVE-2026-11822_4.patch: Fix logic in ext/fts5/fts5_index.c.",
" - CVE-2026-11822",
" - CVE-2026-11824",
""
],
"package": "sqlite3",
"version": "3.46.1-8ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Tue, 16 Jun 2026 13:52:28 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libssh2-1t64",
"from_version": {
"source_package_name": "libssh2",
"source_package_version": "1.11.1-1ubuntu0.25.10.1",
"version": "1.11.1-1ubuntu0.25.10.1"
},
"to_version": {
"source_package_name": "libssh2",
"source_package_version": "1.11.1-1ubuntu0.25.10.2",
"version": "1.11.1-1ubuntu0.25.10.2"
},
"cves": [
{
"cve": "CVE-2025-15661",
"url": "https://ubuntu.com/security/CVE-2025-15661",
"cve_description": "libssh2 through 1.11.1, fixed in commit 2dae302, contains an out-of-bounds heap read vulnerability in the sftp_symlink() function in src/sftp.c that allows a malicious SSH server or man-in-the-middle attacker to disclose heap memory contents or cause a crash by sending a crafted SSH_FXP_NAME response. Attackers can supply a link_len value larger than the actual packet data in SSH_FXP_NAME responses for SFTP READLINK and REALPATH operations, triggering a heap buffer over-read of up to target_len minus one bytes due to the missing validation of available packet buffer size before the memcpy operation.",
"cve_priority": "medium",
"cve_public_date": "2026-06-18 21:16:00 UTC"
},
{
"cve": "CVE-2026-55199",
"url": "https://ubuntu.com/security/CVE-2026-55199",
"cve_description": "libssh2 through 1.11.1, fixed in commit 1762685, contains a pre-authentication denial of service vulnerability in the SSH_MSG_EXT_INFO handler in src/packet.c that allows a malicious SSH server to cause a client CPU exhaustion loop by sending a crafted extension count value. A malicious server can set nr_extensions to 0xFFFFFFFF during key exchange, causing the client to spin in a tight CPU loop for over 60 seconds because return values from _libssh2_get_string() are unchecked and the session timeout does not apply to CPU-bound loops.",
"cve_priority": "medium",
"cve_public_date": "2026-06-17 20:17:00 UTC"
},
{
"cve": "CVE-2026-55200",
"url": "https://ubuntu.com/security/CVE-2026-55200",
"cve_description": "libssh2 through 1.11.1, fixed in commit 7acf3df contains an out-of-bounds write vulnerability in ssh2_transport_read() that fails to enforce upper bounds on packet_length field. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.",
"cve_priority": "medium",
"cve_public_date": "2026-06-17 20:17:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-15661",
"url": "https://ubuntu.com/security/CVE-2025-15661",
"cve_description": "libssh2 through 1.11.1, fixed in commit 2dae302, contains an out-of-bounds heap read vulnerability in the sftp_symlink() function in src/sftp.c that allows a malicious SSH server or man-in-the-middle attacker to disclose heap memory contents or cause a crash by sending a crafted SSH_FXP_NAME response. Attackers can supply a link_len value larger than the actual packet data in SSH_FXP_NAME responses for SFTP READLINK and REALPATH operations, triggering a heap buffer over-read of up to target_len minus one bytes due to the missing validation of available packet buffer size before the memcpy operation.",
"cve_priority": "medium",
"cve_public_date": "2026-06-18 21:16:00 UTC"
},
{
"cve": "CVE-2026-55199",
"url": "https://ubuntu.com/security/CVE-2026-55199",
"cve_description": "libssh2 through 1.11.1, fixed in commit 1762685, contains a pre-authentication denial of service vulnerability in the SSH_MSG_EXT_INFO handler in src/packet.c that allows a malicious SSH server to cause a client CPU exhaustion loop by sending a crafted extension count value. A malicious server can set nr_extensions to 0xFFFFFFFF during key exchange, causing the client to spin in a tight CPU loop for over 60 seconds because return values from _libssh2_get_string() are unchecked and the session timeout does not apply to CPU-bound loops.",
"cve_priority": "medium",
"cve_public_date": "2026-06-17 20:17:00 UTC"
},
{
"cve": "CVE-2026-55200",
"url": "https://ubuntu.com/security/CVE-2026-55200",
"cve_description": "libssh2 through 1.11.1, fixed in commit 7acf3df contains an out-of-bounds write vulnerability in ssh2_transport_read() that fails to enforce upper bounds on packet_length field. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.",
"cve_priority": "medium",
"cve_public_date": "2026-06-17 20:17:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: OOB read in sftp_symlink()",
" - debian/patches/CVE-2025-15661-pre1.patch: add LIBSSH2_UNCONST() in",
" src/libssh2_priv.h.",
" - debian/patches/CVE-2025-15661.patch: Update sftp_symlink to avoid out of",
" bounds read on malformed packet in src/sftp.c.",
" - CVE-2025-15661",
" * SECURITY UPDATE: pre-authentication denial of service via CPU loop",
" - debian/patches/CVE-2026-55199.patch: packet: check `_libssh2_get_string()`",
" return in `EXT_INFO` handler in src/packet.c.",
" - CVE-2026-55199",
" * SECURITY UPDATE: code exec via OOB write in ssh2_transport_read()",
" - debian/patches/CVE-2026-55200.patch: transport.c: Additional boundary",
" checks for packet length in src/transport.c.",
" - CVE-2026-55200",
""
],
"package": "libssh2",
"version": "1.11.1-1ubuntu0.25.10.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Mon, 29 Jun 2026 09:13:22 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libtinfo6",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libxml2-16",
"from_version": {
"source_package_name": "libxml2",
"source_package_version": "2.14.5+dfsg-0.2ubuntu0.1",
"version": "2.14.5+dfsg-0.2ubuntu0.1"
},
"to_version": {
"source_package_name": "libxml2",
"source_package_version": "2.14.5+dfsg-0.2ubuntu0.2",
"version": "2.14.5+dfsg-0.2ubuntu0.2"
},
"cves": [
{
"cve": "CVE-2026-1757",
"url": "https://ubuntu.com/security/CVE-2026-1757",
"cve_description": "A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.",
"cve_priority": "low",
"cve_public_date": "2026-02-02 13:15:00 UTC"
},
{
"cve": "CVE-2026-6732",
"url": "https://ubuntu.com/security/CVE-2026-6732",
"cve_description": "A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 23:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-1757",
"url": "https://ubuntu.com/security/CVE-2026-1757",
"cve_description": "A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.",
"cve_priority": "low",
"cve_public_date": "2026-02-02 13:15:00 UTC"
},
{
"cve": "CVE-2026-6732",
"url": "https://ubuntu.com/security/CVE-2026-6732",
"cve_description": "A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 23:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Denial of service in xmllint.",
" - debian/patches/CVE-2026-1757.patch: Free the cmdline when it only",
" contains whitespace in shell.c",
" - CVE-2026-1757",
" * SECURITY UPDATE: Denial of service in parser.",
" - debian/patches/CVE-2026-6732.patch: Pass userData instead of ctxt in",
" parser.c",
" - CVE-2026-6732",
""
],
"package": "libxml2",
"version": "2.14.5+dfsg-0.2ubuntu0.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Fri, 19 Jun 2026 11:46:21 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-headers-generic",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-40.40",
""
],
"package": "linux-meta",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 16:26:36 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-39.39",
""
],
"package": "linux-meta",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 23:56:49 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-38.38",
""
],
"package": "linux-meta",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:49:35 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-36.36",
""
],
"package": "linux-meta",
"version": "6.17.0-36.36",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 01:59:48 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-33.33",
""
],
"package": "linux-meta",
"version": "6.17.0-33.33",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 22 May 2026 23:14:40 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-headers-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-40.40",
""
],
"package": "linux-meta",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 16:26:36 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-39.39",
""
],
"package": "linux-meta",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 23:56:49 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-38.38",
""
],
"package": "linux-meta",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:49:35 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-36.36",
""
],
"package": "linux-meta",
"version": "6.17.0-36.36",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 01:59:48 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-33.33",
""
],
"package": "linux-meta",
"version": "6.17.0-33.33",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 22 May 2026 23:14:40 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-image-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-40.40",
""
],
"package": "linux-meta",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 16:26:36 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-39.39",
""
],
"package": "linux-meta",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 23:56:49 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-38.38",
""
],
"package": "linux-meta",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:49:35 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-36.36",
""
],
"package": "linux-meta",
"version": "6.17.0-36.36",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 01:59:48 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-33.33",
""
],
"package": "linux-meta",
"version": "6.17.0-33.33",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 22 May 2026 23:14:40 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-libc-dev",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-perf",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-tools-common",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-40.40",
""
],
"package": "linux-meta",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 16:26:36 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-39.39",
""
],
"package": "linux-meta",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 23:56:49 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-38.38",
""
],
"package": "linux-meta",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:49:35 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-36.36",
""
],
"package": "linux-meta",
"version": "6.17.0-36.36",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 01:59:48 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-33.33",
""
],
"package": "linux-meta",
"version": "6.17.0-33.33",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Edoardo Canepa ",
"date": "Fri, 22 May 2026 23:14:40 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "ncurses-base",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "ncurses-bin",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "ncurses-term",
"from_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2build1",
"version": "6.5+20250216-2build1"
},
"to_version": {
"source_package_name": "ncurses",
"source_package_version": "6.5+20250216-2ubuntu0.1",
"version": "6.5+20250216-2ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-69720",
"url": "https://ubuntu.com/security/CVE-2025-69720",
"cve_description": "The infocmp command-line tool in ncurses before 6.5-20251213 has a stack-based buffer overflow in analyze_string in progs/infocmp.c.",
"cve_priority": "low",
"cve_public_date": "2026-03-19 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: stack-based buffer overflow in infocmp",
" - debian/patches/CVE-2025-69720.patch: clamp length to",
" MAX_TERMINFO_LENGTH before copying into buf2 in analyze_string.",
" - CVE-2025-69720",
""
],
"package": "ncurses",
"version": "6.5+20250216-2ubuntu0.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Paulo Flabiano Smorigo ",
"date": "Tue, 30 Jun 2026 21:25:27 +0000"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "perl",
"from_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6build1",
"version": "5.40.1-6build1"
},
"to_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6ubuntu0.1",
"version": "5.40.1-6ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: path traversal in Archive::Tar symlink/hardlink extraction",
" - debian/patches/CVE-2026-42496.patch: validate symlink and hardlink",
" targets against absolute paths and directory traversal in",
" cpan/Archive-Tar/lib/Archive/Tar.pm",
" - CVE-2026-42496",
" * SECURITY UPDATE: integer overflow in regular expression compiler",
" - debian/patches/CVE-2026-8376_1.patch: add test cases for heap buffer",
" overflow via quantified fixed-string regex in t/re/pat_psycho.t",
" - debian/patches/CVE-2026-8376_2.patch: add overflow check before",
" fixed-string buffer allocation in regcomp.c / regcomp_study.c",
" - CVE-2026-8376",
" * debian/rules: temporarily disable flaky op/magic.t test during build",
" in questing environment to allow security updates to proceed",
""
],
"package": "perl",
"version": "5.40.1-6ubuntu0.1",
"urgency": "high",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Chrisa Oikonomou ",
"date": "Fri, 12 Jun 2026 16:42:19 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "perl-base",
"from_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6build1",
"version": "5.40.1-6build1"
},
"to_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6ubuntu0.1",
"version": "5.40.1-6ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: path traversal in Archive::Tar symlink/hardlink extraction",
" - debian/patches/CVE-2026-42496.patch: validate symlink and hardlink",
" targets against absolute paths and directory traversal in",
" cpan/Archive-Tar/lib/Archive/Tar.pm",
" - CVE-2026-42496",
" * SECURITY UPDATE: integer overflow in regular expression compiler",
" - debian/patches/CVE-2026-8376_1.patch: add test cases for heap buffer",
" overflow via quantified fixed-string regex in t/re/pat_psycho.t",
" - debian/patches/CVE-2026-8376_2.patch: add overflow check before",
" fixed-string buffer allocation in regcomp.c / regcomp_study.c",
" - CVE-2026-8376",
" * debian/rules: temporarily disable flaky op/magic.t test during build",
" in questing environment to allow security updates to proceed",
""
],
"package": "perl",
"version": "5.40.1-6ubuntu0.1",
"urgency": "high",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Chrisa Oikonomou ",
"date": "Fri, 12 Jun 2026 16:42:19 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "perl-modules-5.40",
"from_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6build1",
"version": "5.40.1-6build1"
},
"to_version": {
"source_package_name": "perl",
"source_package_version": "5.40.1-6ubuntu0.1",
"version": "5.40.1-6ubuntu0.1"
},
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-42496",
"url": "https://ubuntu.com/security/CVE-2026-42496",
"cve_description": "Archive::Tar versions before 3.08 for Perl extract symlinks with attacker controlled targets outside the extraction directory. _make_special_file() passes the tar header's linkname to symlink() without validating it against absolute paths or .. segments. The secure-extract mode check that guards regular file extraction does not cover the symlink target. A subsequent open through the extracted name reads or writes the attacker chosen path.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 02:16:00 UTC"
},
{
"cve": "CVE-2026-8376",
"url": "https://ubuntu.com/security/CVE-2026-8376",
"cve_description": "Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.",
"cve_priority": "medium",
"cve_public_date": "2026-05-26 00:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: path traversal in Archive::Tar symlink/hardlink extraction",
" - debian/patches/CVE-2026-42496.patch: validate symlink and hardlink",
" targets against absolute paths and directory traversal in",
" cpan/Archive-Tar/lib/Archive/Tar.pm",
" - CVE-2026-42496",
" * SECURITY UPDATE: integer overflow in regular expression compiler",
" - debian/patches/CVE-2026-8376_1.patch: add test cases for heap buffer",
" overflow via quantified fixed-string regex in t/re/pat_psycho.t",
" - debian/patches/CVE-2026-8376_2.patch: add overflow check before",
" fixed-string buffer allocation in regcomp.c / regcomp_study.c",
" - CVE-2026-8376",
" * debian/rules: temporarily disable flaky op/magic.t test during build",
" in questing environment to allow security updates to proceed",
""
],
"package": "perl",
"version": "5.40.1-6ubuntu0.1",
"urgency": "high",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Chrisa Oikonomou ",
"date": "Fri, 12 Jun 2026 16:42:19 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.7",
"version": "2:9.1.0967-1ubuntu6.7"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.8",
"version": "2:9.1.0967-1ubuntu6.8"
},
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Out-of-bounds write.",
" - debian/patches/CVE-2026-55693.patch: only descend while",
" depth < MAXWLEN - 1 in src/spellfile.c.",
" - debian/patches/CVE-2026-55892.patch: only descend while",
" depth < MAXWLEN - 1 in src/spell.c.",
" - CVE-2026-55693",
" - CVE-2026-55892",
" * SECURITY UPDATE: Code injection in local file deletion.",
" - debian/patches/CVE-2026-55895.patch: Use fnameescape() to escape",
" file name in runtime/autoload/netrw.vim.",
" - CVE-2026-55895",
" * SECURITY UPDATE: Out-of-bounds read with sodium encrypted files.",
" - debian/patches/CVE-2026-57452.patch: Verify that there is enough space",
" before function call in src/crypt.c.",
" - CVE-2026-57452",
" * SECURITY UPDATE: Out-of-bounds write with soundfold().",
" - debian/patches/CVE-2026-57455.patch: Add an abort condition to validate",
" buffer in src/spell.c.",
" - CVE-2026-57455",
" * SECURITY UPDATE: Code execution with python complete.",
" - debian/patches/CVE-2026-57456.patch: Use repr() to quote the doc strings",
" in runtime/autoload/python3complete.vim and ../pythoncomplete.vim.",
" - CVE-2026-57456",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.8",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Tue, 30 Jun 2026 11:36:30 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-common",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.7",
"version": "2:9.1.0967-1ubuntu6.7"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.8",
"version": "2:9.1.0967-1ubuntu6.8"
},
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Out-of-bounds write.",
" - debian/patches/CVE-2026-55693.patch: only descend while",
" depth < MAXWLEN - 1 in src/spellfile.c.",
" - debian/patches/CVE-2026-55892.patch: only descend while",
" depth < MAXWLEN - 1 in src/spell.c.",
" - CVE-2026-55693",
" - CVE-2026-55892",
" * SECURITY UPDATE: Code injection in local file deletion.",
" - debian/patches/CVE-2026-55895.patch: Use fnameescape() to escape",
" file name in runtime/autoload/netrw.vim.",
" - CVE-2026-55895",
" * SECURITY UPDATE: Out-of-bounds read with sodium encrypted files.",
" - debian/patches/CVE-2026-57452.patch: Verify that there is enough space",
" before function call in src/crypt.c.",
" - CVE-2026-57452",
" * SECURITY UPDATE: Out-of-bounds write with soundfold().",
" - debian/patches/CVE-2026-57455.patch: Add an abort condition to validate",
" buffer in src/spell.c.",
" - CVE-2026-57455",
" * SECURITY UPDATE: Code execution with python complete.",
" - debian/patches/CVE-2026-57456.patch: Use repr() to quote the doc strings",
" in runtime/autoload/python3complete.vim and ../pythoncomplete.vim.",
" - CVE-2026-57456",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.8",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Tue, 30 Jun 2026 11:36:30 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-runtime",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.7",
"version": "2:9.1.0967-1ubuntu6.7"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.8",
"version": "2:9.1.0967-1ubuntu6.8"
},
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Out-of-bounds write.",
" - debian/patches/CVE-2026-55693.patch: only descend while",
" depth < MAXWLEN - 1 in src/spellfile.c.",
" - debian/patches/CVE-2026-55892.patch: only descend while",
" depth < MAXWLEN - 1 in src/spell.c.",
" - CVE-2026-55693",
" - CVE-2026-55892",
" * SECURITY UPDATE: Code injection in local file deletion.",
" - debian/patches/CVE-2026-55895.patch: Use fnameescape() to escape",
" file name in runtime/autoload/netrw.vim.",
" - CVE-2026-55895",
" * SECURITY UPDATE: Out-of-bounds read with sodium encrypted files.",
" - debian/patches/CVE-2026-57452.patch: Verify that there is enough space",
" before function call in src/crypt.c.",
" - CVE-2026-57452",
" * SECURITY UPDATE: Out-of-bounds write with soundfold().",
" - debian/patches/CVE-2026-57455.patch: Add an abort condition to validate",
" buffer in src/spell.c.",
" - CVE-2026-57455",
" * SECURITY UPDATE: Code execution with python complete.",
" - debian/patches/CVE-2026-57456.patch: Use repr() to quote the doc strings",
" in runtime/autoload/python3complete.vim and ../pythoncomplete.vim.",
" - CVE-2026-57456",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.8",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Tue, 30 Jun 2026 11:36:30 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-tiny",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.7",
"version": "2:9.1.0967-1ubuntu6.7"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.8",
"version": "2:9.1.0967-1ubuntu6.8"
},
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Out-of-bounds write.",
" - debian/patches/CVE-2026-55693.patch: only descend while",
" depth < MAXWLEN - 1 in src/spellfile.c.",
" - debian/patches/CVE-2026-55892.patch: only descend while",
" depth < MAXWLEN - 1 in src/spell.c.",
" - CVE-2026-55693",
" - CVE-2026-55892",
" * SECURITY UPDATE: Code injection in local file deletion.",
" - debian/patches/CVE-2026-55895.patch: Use fnameescape() to escape",
" file name in runtime/autoload/netrw.vim.",
" - CVE-2026-55895",
" * SECURITY UPDATE: Out-of-bounds read with sodium encrypted files.",
" - debian/patches/CVE-2026-57452.patch: Verify that there is enough space",
" before function call in src/crypt.c.",
" - CVE-2026-57452",
" * SECURITY UPDATE: Out-of-bounds write with soundfold().",
" - debian/patches/CVE-2026-57455.patch: Add an abort condition to validate",
" buffer in src/spell.c.",
" - CVE-2026-57455",
" * SECURITY UPDATE: Code execution with python complete.",
" - debian/patches/CVE-2026-57456.patch: Use repr() to quote the doc strings",
" in runtime/autoload/python3complete.vim and ../pythoncomplete.vim.",
" - CVE-2026-57456",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.8",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Tue, 30 Jun 2026 11:36:30 -0600"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "xxd",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.7",
"version": "2:9.1.0967-1ubuntu6.7"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.8",
"version": "2:9.1.0967-1ubuntu6.8"
},
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-55693",
"url": "https://ubuntu.com/security/CVE-2026-55693",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0653, the tree_count_words() function in src/spellfile.c fills in the word-count fields of a spell-file word trie by walking it iteratively with a depth counter. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (arridx[], curi[], wordcount[]). A crafted .spl/.sug file pair, loaded when the user invokes spell suggestion, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0653.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55892",
"url": "https://ubuntu.com/security/CVE-2026-55892",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-55895",
"url": "https://ubuntu.com/security/CVE-2026-55895",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0663, a Vimscript code injection vulnerability exists in s:NetrwLocalRmFile() in the netrw plugin (runtime/pack/dist/opt/netrw/autoload/netrw.vim) when deleting a local file from the browser. A filename derived from the buffer's directory listing is interpolated into an Ex command line passed to :execute with only the backslash character escaped, allowing a crafted filename containing a bar (|) to terminate the intended command and execute arbitrary Vimscript, including shell commands via :call system() and :!. This vulnerability is fixed in 9.2.0663.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57452",
"url": "https://ubuntu.com/security/CVE-2026-57452",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57455",
"url": "https://ubuntu.com/security/CVE-2026-57455",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
},
{
"cve": "CVE-2026-57456",
"url": "https://ubuntu.com/security/CVE-2026-57456",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0699, Vim's Python omni-completion (runtime/autoload/python3complete.vim and the legacy pythoncomplete.vim) executes reconstructed function and class definitions from the current buffer with exec() as part of populating the completion dictionary. When reconstructing that source, each scope's docstring is inserted verbatim between triple quotes with no escaping, so a hostile buffer can break out of the triple-quoted literal and execute attacker-controlled Python during omni-completion. This vulnerability is fixed in 9.2.0699.",
"cve_priority": "medium",
"cve_public_date": "2026-06-25 16:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Out-of-bounds write.",
" - debian/patches/CVE-2026-55693.patch: only descend while",
" depth < MAXWLEN - 1 in src/spellfile.c.",
" - debian/patches/CVE-2026-55892.patch: only descend while",
" depth < MAXWLEN - 1 in src/spell.c.",
" - CVE-2026-55693",
" - CVE-2026-55892",
" * SECURITY UPDATE: Code injection in local file deletion.",
" - debian/patches/CVE-2026-55895.patch: Use fnameescape() to escape",
" file name in runtime/autoload/netrw.vim.",
" - CVE-2026-55895",
" * SECURITY UPDATE: Out-of-bounds read with sodium encrypted files.",
" - debian/patches/CVE-2026-57452.patch: Verify that there is enough space",
" before function call in src/crypt.c.",
" - CVE-2026-57452",
" * SECURITY UPDATE: Out-of-bounds write with soundfold().",
" - debian/patches/CVE-2026-57455.patch: Add an abort condition to validate",
" buffer in src/spell.c.",
" - CVE-2026-57455",
" * SECURITY UPDATE: Code execution with python complete.",
" - debian/patches/CVE-2026-57456.patch: Use repr() to quote the doc strings",
" in runtime/autoload/python3complete.vim and ../pythoncomplete.vim.",
" - CVE-2026-57456",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.8",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Kyle Kernick ",
"date": "Tue, 30 Jun 2026 11:36:30 -0600"
}
],
"notes": null,
"is_version_downgrade": false
}
],
"snap": []
},
"added": {
"deb": [
{
"name": "linux-headers-6.17.0-40",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": "linux-headers-6.17.0-40 version '6.17.0-40.40' (source package linux version '6.17.0-40.40') was added. linux-headers-6.17.0-40 version '6.17.0-40.40' has the same source package name, linux, as removed package linux-headers-6.17.0-35. As such we can use the source package version of the removed package, '6.17.0-35.35', 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-headers-6.17.0-40-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": "linux-headers-6.17.0-40-generic version '6.17.0-40.40' (source package linux version '6.17.0-40.40') was added. linux-headers-6.17.0-40-generic version '6.17.0-40.40' has the same source package name, linux, as removed package linux-headers-6.17.0-35. As such we can use the source package version of the removed package, '6.17.0-35.35', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-image-6.17.0-40-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [],
"launchpad_bugs_fixed": [
1786013,
1786013,
1786013,
1786013,
1786013
],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-40.40",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 16:26:46 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-39.39",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 23:56:58 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-38.38",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:50:17 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-36.36",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-36.36",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 02:08:15 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-33.33",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-33.33",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Edoardo Canepa ",
"date": "Fri, 22 May 2026 23:14:52 +0200"
}
],
"notes": "linux-image-6.17.0-40-generic version '6.17.0-40.40' (source package linux-signed version '6.17.0-40.40') was added. linux-image-6.17.0-40-generic version '6.17.0-40.40' has the same source package name, linux-signed, as removed package linux-image-6.17.0-35-generic. As such we can use the source package version of the removed package, '6.17.0-35.35', 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.17.0-40-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": "linux-modules-6.17.0-40-generic version '6.17.0-40.40' (source package linux version '6.17.0-40.40') was added. linux-modules-6.17.0-40-generic version '6.17.0-40.40' has the same source package name, linux, as removed package linux-headers-6.17.0-35. As such we can use the source package version of the removed package, '6.17.0-35.35', 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-tools-6.17.0-40",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": "linux-tools-6.17.0-40 version '6.17.0-40.40' (source package linux version '6.17.0-40.40') was added. linux-tools-6.17.0-40 version '6.17.0-40.40' has the same source package name, linux, as removed package linux-headers-6.17.0-35. As such we can use the source package version of the removed package, '6.17.0-35.35', 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-tools-6.17.0-40-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-40.40",
"version": "6.17.0-40.40"
},
"cves": [
{
"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-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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
},
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2157631,
2157145,
1786013,
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"changes": [
{
"cves": [
{
"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"
}
],
"log": [
"",
" * questing/linux: 6.17.0-40.40 -proposed tracker (LP: #2157631)",
"",
" * CVE-2026-43037",
" - ip6_tunnel: clear skb2->cb[] in ip4ip6_err()",
""
],
"package": "linux",
"version": "6.17.0-40.40",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157631
],
"author": "Manuel Diewald ",
"date": "Fri, 19 Jun 2026 15:57:33 +0200"
},
{
"cves": [
{
"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-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-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-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-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-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-46266",
"url": "https://ubuntu.com/security/CVE-2026-46266",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP Yizhou Zhao reported that simply having one RAW socket on protocol IPPROTO_RAW (255) was dangerous. socket(AF_INET, SOCK_RAW, 255); A malicious incoming ICMP packet can set the protocol field to 255 and match this socket, leading to FNHE cache changes. inner = IP(src=\"192.168.2.1\", dst=\"8.8.8.8\", proto=255)/Raw(\"TEST\") pkt = IP(src=\"192.168.1.1\", dst=\"192.168.2.1\")/ICMP(type=3, code=4, nexthopmtu=576)/inner \"man 7 raw\" states: A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able to send any IP protocol that is specified in the passed header. Receiving of all IP protocols via IPPROTO_RAW is not possible using raw sockets. Make sure we drop these malicious packets.",
"cve_priority": "medium",
"cve_public_date": "2026-06-03 18: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-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-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-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-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-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-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-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-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-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-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-45898",
"url": "https://ubuntu.com/security/CVE-2026-45898",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list The commit e1168f0 (\"RDMA/iwcm: Simplify cm_event_handler()\") changed the work submission logic to unconditionally call queue_work() with the expectation that queue_work() would have no effect if work was already pending. The problem is that a free list of struct iwcm_work is used (for which struct work_struct is embedded), so each call to queue_work() is basically unique and therefore does indeed queue the work. This causes a problem in the work handler which walks the work_list until it's empty to process entries. This means that a single run of the work handler could process item N+1 and release it back to the free list while the actual workqueue entry is still queued. It could then get reused (INIT_WORK...) and lead to list corruption in the workqueue logic. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08) [ 151.466639] ------------[ cut here ]------------ [ 151.466986] kernel BUG at lib/list_debug.c:67! [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] ",
"cve_priority": "medium",
"cve_public_date": "2026-05-27 14:17: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-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-43186",
"url": "https://ubuntu.com/security/CVE-2026-43186",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() On the receive path, __ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skb_shared_info), which corrupts adjacent heap memory and leads to a kernel panic. Add a shared helper ioam6_trace_compute_nodelen() in ioam6.c to derive the expected nodelen from the type field, and use it: - in ioam6_iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written. Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to 0xff1ffc00).",
"cve_priority": "high",
"cve_public_date": "2026-05-06 12: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-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-46325",
"url": "https://ubuntu.com/security/CVE-2026-46325",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 14: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-43197",
"url": "https://ubuntu.com/security/CVE-2026-43197",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netconsole: avoid OOB reads, msg is not nul-terminated msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 (\"netconsole: convert to NBCON console infrastructure\") the message would be placed in printk_shared_pbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see: printk: console [netcon_ext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594 CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasan_report+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsole_write+0x3fe/0xa10 nbcon_emit_next_record+0x46e/0x860 nbcon_kthread_func+0x623/0x750 Allocated by task 1: nbcon_alloc+0x1ea/0x450 register_console+0x26b/0xe10 init_netconsole+0xbb0/0xda0 The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)",
"cve_priority": "negligible",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-43083",
"url": "https://ubuntu.com/security/CVE-2026-43083",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.",
"cve_priority": "high",
"cve_public_date": "2026-05-06 10:16: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-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-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-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-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-46039",
"url": "https://ubuntu.com/security/CVE-2026-46039",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxgk: Fix potential integer overflow in length check Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data.",
"cve_priority": "high",
"cve_public_date": "2026-05-27 14:17:00 UTC"
},
{
"cve": "CVE-2026-23427",
"url": "https://ubuntu.com/security/CVE-2026-23427",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in durable v2 replay of active file handles parse_durable_handle_context() unconditionally assigns dh_info->fp->conn to the current connection when handling a DURABLE_REQ_V2 context with SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by fp->conn, so it returns file handles that are already actively connected. The unconditional overwrite replaces fp->conn, and when the overwriting connection is subsequently freed, __ksmbd_close_fd() dereferences the stale fp->conn via spin_lock(&fp->conn->llist_lock), causing a use-after-free. KASAN report: [ 7.349357] ================================================================== [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0 [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108 [ 7.350010] [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY [ 7.350068] 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 [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work [ 7.350083] Call Trace: [ 7.350087] [ 7.350087] dump_stack_lvl+0x64/0x80 [ 7.350094] print_report+0xce/0x660 [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 7.350101] ? __pfx___mod_timer+0x10/0x10 [ 7.350106] ? _raw_spin_lock+0x75/0xe0 [ 7.350108] kasan_report+0xce/0x100 [ 7.350109] ? _raw_spin_lock+0x75/0xe0 [ 7.350114] kasan_check_range+0x105/0x1b0 [ 7.350116] _raw_spin_lock+0x75/0xe0 [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780 [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0 [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0 [ 7.350131] ksmbd_close_fd+0x135/0x1b0 [ 7.350133] smb2_close+0xb19/0x15b0 [ 7.350142] ? __pfx_smb2_close+0x10/0x10 [ 7.350143] ? xas_load+0x18/0x270 [ 7.350146] ? _raw_spin_lock+0x84/0xe0 [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10 [ 7.350150] ? _raw_spin_unlock+0xe/0x30 [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0 [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0 [ 7.350154] handle_ksmbd_work+0x40f/0x1080 [ 7.350156] process_one_work+0x5fa/0xef0 [ 7.350162] ? assign_work+0x122/0x3e0 [ 7.350163] worker_thread+0x54b/0xf70 [ 7.350165] ? __pfx_worker_thread+0x10/0x10 [ 7.350166] kthread+0x346/0x470 [ 7.350170] ? recalc_sigpending+0x19b/0x230 [ 7.350176] ? __pfx_kthread+0x10/0x10 [ 7.350178] ret_from_fork+0x4fb/0x6c0 [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10 [ 7.350185] ? __switch_to+0x36c/0xbe0 [ 7.350188] ? __pfx_kthread+0x10/0x10 [ 7.350190] ret_from_fork_asm+0x1a/0x30 [ 7.350197] [ 7.350197] [ 7.355160] Allocated by task 123: [ 7.355261] kasan_save_stack+0x33/0x60 [ 7.355373] kasan_save_track+0x14/0x30 [ 7.355484] __kasan_kmalloc+0x8f/0xa0 [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0 [ 7.355711] ksmbd_kthread_fn+0x243/0xd70 [ 7.355839] kthread+0x346/0x470 [ 7.355942] ret_from_fork+0x4fb/0x6c0 [ 7.356051] ret_from_fork_asm+0x1a/0x30 [ 7.356164] [ 7.356214] Freed by task 134: [ 7.356305] kasan_save_stack+0x33/0x60 [ 7.356416] kasan_save_track+0x14/0x30 [ 7.356527] kasan_save_free_info+0x3b/0x60 [ 7.356646] __kasan_slab_free+0x43/0x70 [ 7.356761] kfree+0x1ca/0x430 [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0 [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40 [ 7.357138] kthread+0x346/0x470 [ 7.357240] ret_from_fork+0x4fb/0x6c0 [ 7.357350] ret_from_fork_asm+0x1a/0x30 [ 7.357463] [ 7.357513] The buggy address belongs to the object at ffff8881056ac000 [ 7.357513] which belongs to the cache kmalloc-1k of size 1024 [ 7.357857] The buggy address is located 396 bytes inside of [ 7.357857] freed 1024-byte region ---truncated---",
"cve_priority": "high",
"cve_public_date": "2026-04-03 16:16:00 UTC"
},
{
"cve": "CVE-2026-31718",
"url": "https://ubuntu.com/security/CVE-2026-31718",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger When a durable file handle survives session disconnect (TCP close without SMB2_LOGOFF), session_fd_check() sets fp->conn = NULL to preserve the handle for later reconnection. However, it did not clean up the byte-range locks on fp->lock_list. Later, when the durable scavenger thread times out and calls __ksmbd_close_fd(NULL, fp), the lock cleanup loop did: spin_lock(&fp->conn->llist_lock); This caused a slab use-after-free because fp->conn was NULL and the original connection object had already been freed by ksmbd_tcp_disconnect(). The root cause is asymmetric cleanup: lock entries (smb_lock->clist) were left dangling on the freed conn->lock_list while fp->conn was nulled out. To fix this issue properly, we need to handle the lifetime of smb_lock->clist across three paths: - Safely skip clist deletion when list is empty and fp->conn is NULL. - Remove the lock from the old connection's lock_list in session_fd_check() - Re-add the lock to the new connection's lock_list in ksmbd_reopen_durable_fd().",
"cve_priority": "high",
"cve_public_date": "2026-05-01 14: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-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-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-31635",
"url": "https://ubuntu.com/security/CVE-2026-31635",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix oversized RESPONSE authenticator length check rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 15: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-43125",
"url": "https://ubuntu.com/security/CVE-2026-43125",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: validate length in dlm_search_rsb_tree The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree(). Add length validation to prevent potential buffer overflow.",
"cve_priority": "critical",
"cve_public_date": "2026-05-06 12:16:00 UTC"
},
{
"cve": "CVE-2026-46316",
"url": "https://ubuntu.com/security/CVE-2026-46316",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry vgic_its_invalidate_cache() walks the per-ITS translation cache with xa_for_each() and drops the cache's reference on each entry with vgic_put_irq(). It puts the iterated pointer, though, rather than the value returned by xa_erase(). The function is called from contexts that do not exclude one another: the ITS command handlers hold its_lock, the GITS_CTLR write path holds cmd_lock, and the path that clears EnableLPIs in a redistributor's GICR_CTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it. xa_erase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.",
"cve_priority": "medium",
"cve_public_date": "2026-06-09 13: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-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-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-43402",
"url": "https://ubuntu.com/security/CVE-2026-43402",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: consolidate kthread exit paths to prevent use-after-free Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rb_node with an 8-byte rhash_head in struct pid, shrinking it from 160 to 144 bytes. struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinity_node both sit at offset 0x78. When a kthread exits via make_task_dead() it bypasses kthread_exit() and misses the affinity_node cleanup. free_kthread_struct() frees the memory while the node is still linked into the global kthread_affinity_list. A subsequent list_del() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer. Instead of patching free_kthread_struct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthread_exit() into a macro that calls do_exit() and add kthread_do_exit() which is called from do_exit() for any task with PF_KTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - make_task_dead(), direct do_exit(), or kthread_exit(). Replace __to_kthread() with a new tsk_is_kthread() accessor in the public header. Export do_exit() since module code using the kthread_exit() macro now needs it directly.",
"cve_priority": "low",
"cve_public_date": "2026-05-08 15: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-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-43376",
"url": "https://ubuntu.com/security/CVE-2026-43376",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free by using call_rcu() for oplock_info ksmbd currently frees oplock_info immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfo_get() and proc_show_files(). Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplock_info structure after it has been freed. This can leads to a use-after-free especially in opinfo_get() where atomic_inc_not_zero() is called on already freed memory. Fix this by switching to deferred freeing using call_rcu().",
"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"
},
{
"cve": "CVE-2026-43304",
"url": "https://ubuntu.com/security/CVE-2026-43304",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.",
"cve_priority": "critical",
"cve_public_date": "2026-05-08 14:16:00 UTC"
},
{
"cve": "CVE-2026-22984",
"url": "https://ubuntu.com/security/CVE-2026-22984",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]",
"cve_priority": "high",
"cve_public_date": "2026-01-23 16:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-39.39 -proposed tracker (LP: #2157145)",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] update annotations scripts",
"",
" * CVE-2026-45988",
" - rxrpc: Fix re-decryption of RESPONSE packets",
"",
" * CVE-2026-46135",
" - nvmet-tcp: fix race between ICReq handling and queue teardown",
"",
" * CVE-2026-46195",
" - smb: client: validate dacloffset before building DACL pointers",
"",
" * CVE-2026-31402",
" - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache",
"",
" * CVE-2026-43378",
" - smb: server: fix use-after-free in smb2_open()",
"",
" * CVE-2026-31657",
" - batman-adv: hold claim backbone gateways by reference",
"",
" * CVE-2026-46266",
" - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP",
"",
" * CVE-2026-46289",
" - lib/scatterlist: fix length calculations in extract_kvec_to_sg",
"",
" * CVE-2026-31436",
" - dmaengine: idxd: fix possible wrong descriptor completion in",
" llist_abort_desc()",
"",
" * CVE-2026-31649",
" - net: stmmac: fix integer underflow in chain mode",
"",
" * CVE-2026-31659",
" - batman-adv: reject oversized global TT response buffers",
"",
" * CVE-2026-31448",
" - ext4: avoid infinite loops caused by residual data",
"",
" * CVE-2026-43071",
" - dcache: Limit the minimal number of bucket to two",
"",
" * CVE-2026-31478",
" - ksmbd: replace hardcoded hdr2_len with offsetof() in",
" smb2_calc_max_out_buf_len()",
"",
" * CVE-2026-31682",
" - bridge: br_nd_send: linearize skb before parsing ND options",
"",
" * CVE-2026-43117",
" - btrfs: tracepoints: get correct superblock from dentry in event",
" btrfs_sync_file()",
"",
" * CVE-2026-31669",
" - mptcp: fix slab-use-after-free in __inet_lookup_established",
"",
" * CVE-2026-46115",
" - block: add pgmap check to biovec_phys_mergeable",
"",
" * CVE-2026-45898",
" - RDMA/iwcm: Fix workqueue list corruption by removing work_list",
"",
" * CVE-2026-46244",
" - netfilter: nft_inner: Fix IPv6 inner_thoff desync",
"",
" * CVE-2026-43493",
" - crypto: pcrypt - Fix handling of MAY_BACKLOG requests",
"",
" * CVE-2026-43186",
" - ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()",
"",
" * CVE-2026-31685",
" - netfilter: ip6t_eui64: reject invalid MAC header for all packets",
"",
" * CVE-2026-43114",
" - netfilter: nft_set_pipapo_avx2: don't return non-matching entry on",
" expiry",
"",
" * CVE-2026-46325",
" - RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE",
"",
" * CVE-2026-31668",
" - seg6: separate dst_cache for input and output paths in seg6 lwtunnel",
"",
" * CVE-2026-43197",
" - netconsole: avoid OOB reads, msg is not nul-terminated",
"",
" * CVE-2026-43083",
" - net: ioam6: fix OOB and missing lock",
"",
" * CVE-2026-46043",
" - RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv",
"",
" * 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-46185",
" - smb/client: fix out-of-bounds read in symlink_data()",
"",
" * CVE-2026-23455",
" - netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()",
"",
" * CVE-2026-46119",
" - libceph: Fix slab-out-of-bounds access in auth message processing",
"",
" * CVE-2026-46039",
" - rxgk: Fix potential integer overflow in length check",
"",
" * CVE-2026-23427",
" - ksmbd: fix use-after-free in durable v2 replay of active file handles",
"",
" * CVE-2026-31718",
" - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger",
"",
" * CVE-2026-31637",
" - rxrpc: reject undecryptable rxkad response tickets",
"",
" * CVE-2026-43011",
" - net/x25: Fix potential double free of skb",
"",
" * CVE-2026-43038",
" - ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()",
"",
" * CVE-2026-31635",
" - rxrpc: fix oversized RESPONSE authenticator length check",
"",
" * CVE-2026-43501",
" - ipv6: rpl: reserve mac_len headroom when recompressed SRH grows",
"",
" * CVE-2026-43125",
" - dlm: validate length in dlm_search_rsb_tree",
"",
" * CVE-2026-46316",
" - KVM: arm64: vgic-its: Drop the translation cache reference only for the",
" erased entry",
"",
" * CVE-2026-43185",
" - ksmbd: fix signededness bug in smb_direct_prepare_negotiation()",
"",
" * CVE-2026-43341",
" - net/ipv6: ioam6: prevent schema length wraparound in trace fill",
"",
" * CVE-2026-31607",
" - usbip: validate number_of_packets in usbip_pack_ret_submit()",
"",
" * CVE-2026-43402",
" - kthread: consolidate kthread exit paths to prevent use-after-free",
"",
" * CVE-2026-43384",
" - net/tcp-ao: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43383",
" - net/tcp-md5: Fix MAC comparison to be constant-time",
"",
" * CVE-2026-43376",
" - ksmbd: fix use-after-free by using call_rcu() for oplock_info",
"",
" * 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()",
"",
" * CVE-2026-43304",
" - libceph: define and enforce CEPH_MAX_KEY_LEN",
"",
" * CVE-2026-22984",
" - libceph: prevent potential out-of-bounds reads in handle_auth_done()",
""
],
"package": "linux",
"version": "6.17.0-39.39",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2157145,
1786013
],
"author": "Manuel Diewald ",
"date": "Thu, 18 Jun 2026 22:58:24 +0200"
},
{
"cves": [
{
"cve": "CVE-2026-23272",
"url": "https://ubuntu.com/security/CVE-2026-23272",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-31418",
"url": "https://ubuntu.com/security/CVE-2026-31418",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: drop logically empty buckets in mtype_del mtype_del() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots. Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-23392",
"url": "https://ubuntu.com/security/CVE-2026-23392",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23278",
"url": "https://ubuntu.com/security/CVE-2026-23278",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: always walk all pending catchall elements During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch. If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate. Otherwise, we get: WARNING: ./include/net/netfilter/nf_tables.h:1281 at nft_data_release+0xb7/0xe0 [nf_tables], CPU#2: nft/1404 RIP: 0010:nft_data_release+0xb7/0xe0 [nf_tables] [..] __nft_set_elem_destroy+0x106/0x380 [nf_tables] nf_tables_abort_release+0x348/0x8d0 [nf_tables] nf_tables_abort+0xcf2/0x3ac0 [nf_tables] nfnetlink_rcv_batch+0x9c9/0x20e0 [..]",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-47337",
"url": "https://ubuntu.com/security/CVE-2026-47337",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AF_INET/AF_INET6 socket mediation. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47334",
"url": "https://ubuntu.com/security/CVE-2026-47334",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly sleep while holding a spinlock in notification handling code. The bug can be triggered by an unprivileged local user and can result in kernel panic or deadlock.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47333",
"url": "https://ubuntu.com/security/CVE-2026-47333",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which can potentially incorrectly compute the size of an internal buffer, leading to a heap memory out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in invalid data being processed by the AppArmor DFA policy engine.",
"cve_priority": "high",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47332",
"url": "https://ubuntu.com/security/CVE-2026-47332",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly validate the size of an internal structure, leading to an out-of-bounds read in notification handling code. The bug can be triggered by an unprivileged local user and can result in information disclosure from adjacent slab objects.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47330",
"url": "https://ubuntu.com/security/CVE-2026-47330",
"cve_description": "Ubuntu Linux 6.8, 7.17 and 7.0 contain AppArmor SAUCE patches which can, under certain circumstances, use an uninitialized variable in notification handling code. The bug can be triggered by an unprivileged local user and can result in the incorrect caching of AppArmor notification responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47329",
"url": "https://ubuntu.com/security/CVE-2026-47329",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches which fail to validate invalid sizes of the name field in AppAmor notification responses. The bug can be triggered by an unprivileged local user and could result in handling of crafted responses.",
"cve_priority": "low",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47327",
"url": "https://ubuntu.com/security/CVE-2026-47327",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a possible NULL pointer dereference in the handling of AppArmor notifications. The bug can be triggered by an unprivileged local user. This can lead to a kernel oops.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47328",
"url": "https://ubuntu.com/security/CVE-2026-47328",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain AppArmor SAUCE patches which incorrectly attempt to free a pointer which was not previously kmalloc()d, while at the same time leaking allocated memory. The bug can be triggered by an unprivileged local user and can result in the corruption of slab metadata and could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-47326",
"url": "https://ubuntu.com/security/CVE-2026-47326",
"cve_description": "Ubuntu Linux 6.8, 6.17 and 7.0 contain SAUCE patches with a memory leak in the handling of big responses to AppArmor notifications. The bug can be triggered by an unprivileged local user. The memory leak could lead to resource exhaustion.",
"cve_priority": "medium",
"cve_public_date": "2026-05-28 19:16:00 UTC"
},
{
"cve": "CVE-2026-46300",
"url": "https://ubuntu.com/security/CVE-2026-46300",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.",
"cve_priority": "high",
"cve_public_date": "2026-05-23 12:17:00 UTC"
},
{
"cve": "CVE-2026-46333",
"url": "https://ubuntu.com/security/CVE-2026-46333",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional \"drop capabilities\" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached \"last dumpability\" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.",
"cve_priority": "high",
"cve_public_date": "2026-05-15 14:16:00 UTC"
},
{
"cve": "CVE-2026-43500",
"url": "https://ubuntu.com/security/CVE-2026-43500",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.",
"cve_priority": "high",
"cve_public_date": "2026-05-11 08:16:00 UTC"
},
{
"cve": "CVE-2026-31676",
"url": "https://ubuntu.com/security/CVE-2026-31676",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.",
"cve_priority": "medium",
"cve_public_date": "2026-04-25 09:16:00 UTC"
},
{
"cve": "CVE-2026-43284",
"url": "https://ubuntu.com/security/CVE-2026-43284",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().",
"cve_priority": "high",
"cve_public_date": "2026-05-08 08:16:00 UTC"
},
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-38.38 -proposed tracker (LP: #2154532)",
"",
" * Generic questing kernel oops on bootup with newer Nvidia machines",
" (LP: #2154481)",
" - nouveau: don't attempt fwsec on sb on newer platforms.",
"",
" * Kernel regression (6.8.0-117.generic) (LP: #2153556)",
" - bonding: do not set usable_slaves for broadcast mode",
"",
" * powerpc-build in ubuntu_kernel_selftests fails to build due to",
" uninitialized value (LP: #2129844)",
" - selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15",
"",
" * iptables connlimit traffic loss (LP: #2149872)",
" - netfilter: nf_conncount: fix tracking of connections from localhost",
"",
" * On Dell system, the internal OLED display drops to a visibly low FPS after",
" suspend/resume (LP: #2144712)",
" - drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk",
" - drm/i915/psr: Fixes for Dell XPS DA14260 quirk",
"",
" * CVE-2026-23272",
" - netfilter: nf_tables: unconditionally bump set->nelems before insertion",
"",
" * CVE-2026-31418",
" - netfilter: ipset: drop logically empty buckets in mtype_del",
"",
" * CVE-2026-23392",
" - netfilter: nf_tables: release flowtable after rcu grace period on error",
"",
" * CVE-2026-23278",
" - netfilter: nf_tables: always walk all pending catchall elements",
"",
" * GRO managed-frag use-after-free leading to local privilege escalation",
" (LP: #2154172)",
" - net: gro: don't merge zcopy skbs",
"",
" * AppArmor Vulnerabilities (LP: #2151747)",
" - SAUCE: apparmor: pass big_resp to handler",
" - SAUCE: apparmor: remove redundant kref_init for listener->count",
" - SAUCE: apparmor: fix NULL pointer dereference in unpack_pdb",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47337",
" - SAUCE: apparmor: fix NULL pointer dereference in bind_map_addr",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47334",
" - SAUCE: apparmor: fix sleep prone memory allocation under a spin_lock",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47333",
" - SAUCE: apparmor: fix dfa unpacking size of the notification filter",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47332",
" - SAUCE: apparmor: fix size check against type instead of pointer",
"",
" * apparmor: LLVM/clang build failure due to uninitialized variable in",
" notify.c (LP: #2148809) // CVE-2026-47330",
" - SAUCE: apparmor: initialize variable used in uninitialized context",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47329",
" - SAUCE: apparmor: fix name validation bypass on notification",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47327 //",
" CVE-2026-47328",
" - SAUCE: apparmor: fix glob memory leak after kstrdup",
"",
" * AppArmor Vulnerabilities (LP: #2151747) // CVE-2026-47326",
" - SAUCE: apparmor: fix inverted NULL check after aa_get_buffer",
"",
" * CVE-2026-46300",
" - net: skbuff: preserve shared-frag marker during coalescing",
" - net: skbuff: propagate shared-frag marker through frag-transfer helpers",
"",
" * net/rds: reset op_nents when zerocopy page pin fails (LP: #2153962)",
" - net/rds: reset op_nents when zerocopy page pin fails",
"",
" * CVE-2026-46333",
" - ptrace: slightly saner 'get_dumpable()' logic",
"",
" * CVE-2026-43500",
" - rxrpc: Fix conn-level packet handling to unshare RESPONSE packets",
" - rxrpc: Fix potential UAF after skb_unshare() failure",
" - rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets",
" - rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present",
"",
" * CVE-2026-31676 // CVE-2026-43500",
" - rxrpc: only handle RESPONSE during service challenge",
"",
" * CVE-2026-43284",
" - xfrm: esp: avoid in-place decrypt on shared skb frags",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-38.38",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2154532,
2154481,
2153556,
2129844,
2149872,
2144712,
2154172,
2151747,
2151747,
2151747,
2151747,
2151747,
2148809,
2151747,
2151747,
2151747,
2153962
],
"author": "Edoardo Canepa ",
"date": "Fri, 29 May 2026 03:41:15 +0200"
}
],
"notes": "linux-tools-6.17.0-40-generic version '6.17.0-40.40' (source package linux version '6.17.0-40.40') was added. linux-tools-6.17.0-40-generic version '6.17.0-40.40' has the same source package name, linux, as removed package linux-headers-6.17.0-35. As such we can use the source package version of the removed package, '6.17.0-35.35', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
}
],
"snap": []
},
"removed": {
"deb": [
{
"name": "linux-headers-6.17.0-35",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"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-headers-6.17.0-35-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-image-6.17.0-35-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"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.17.0-35-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"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-tools-6.17.0-35",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"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-tools-6.17.0-35-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-35.35",
"version": "6.17.0-35.35"
},
"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 25.10 questing image from daily image serial 20260621 to 20260703",
"from_series": "questing",
"to_series": "questing",
"from_serial": "20260621",
"to_serial": "20260703",
"from_manifest_filename": "daily_manifest.previous",
"to_manifest_filename": "manifest.current"
}