{ "summary": { "snap": { "added": [], "removed": [], "diff": [ "lxd" ] }, "deb": { "added": [ "linux-headers-5.15.0-187", "linux-headers-5.15.0-187-generic", "linux-image-5.15.0-187-generic", "linux-modules-5.15.0-187-generic" ], "removed": [ "linux-headers-5.15.0-186", "linux-headers-5.15.0-186-generic", "linux-image-5.15.0-186-generic", "linux-modules-5.15.0-186-generic" ], "diff": [ "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-virtual" ] } }, "diff": { "deb": [ { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.186.166", "version": "5.15.0.186.166" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.187.167", "version": "5.15.0.187.167" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-187", "" ], "package": "linux-meta", "version": "5.15.0.187.167", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 18:50:30 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.186.166", "version": "5.15.0.186.166" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.187.167", "version": "5.15.0.187.167" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-187", "" ], "package": "linux-meta", "version": "5.15.0.187.167", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 18:50:30 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.186.166", "version": "5.15.0.186.166" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.187.167", "version": "5.15.0.187.167" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-187", "" ], "package": "linux-meta", "version": "5.15.0.187.167", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 18:50:30 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.186.166", "version": "5.15.0.186.166" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "5.15.0.187.167", "version": "5.15.0.187.167" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-187", "" ], "package": "linux-meta", "version": "5.15.0.187.167", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 18:50:30 +0200" } ], "notes": null, "is_version_downgrade": false } ], "snap": [ { "name": "lxd", "from_version": { "source_package_name": null, "source_package_version": null, "version": "40115" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": "40338" } } ] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-187", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-187.197", "version": "5.15.0-187.197" }, "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2160896, 1786013 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-187.197 -proposed tracker (LP: #2160896)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] update annotations scripts", " - [Packaging] resync retpoline extraction", "", " * CVE-2026-53086", " - net: bcmgenet: fix racing timeout handler", "", " * CVE-2026-53225", " - sctp: fix uninit-value in __sctp_rcv_asconf_lookup()", "", " * CVE-2026-53228", " - ipv6: sit: reload inner IPv6 header after GSO offloads", "", " * CVE-2026-43499", " - rtmutex: Use waiter::task instead of current in remove_waiter()", "", " * CVE-2026-46331", " - net/sched: fix pedit partial COW leading to page cache corruption", "", " * CVE-2026-53212", " - netfilter: nft_tunnel: fix use-after-free on object destroy", "", " * CVE-2026-53359", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", "", " * CVE-2026-52989", " - nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers", "", " * CVE-2026-52924", " - sctp: purge outqueue on stale COOKIE-ECHO handling", "", " * CVE-2026-43378", " - smb: server: fix use-after-free in smb2_open()", "", " * CVE-2025-27558", " - wifi: prevent A-MSDU attacks in mesh networks", "", " * CVE-2026-53215", " - net: mvpp2: refill RX buffers before XDP or skb use", "", " * CVE-2026-53176", " - IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN", "", " * CVE-2026-46266", " - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP", "", " * CVE-2026-43198", " - tcp: fix potential race in tcp_v6_syn_recv_sock()", "", " * CVE-2026-31705", " - ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment", "", " * CVE-2026-31448", " - ext4: avoid infinite loops caused by residual data", "", " * CVE-2026-31414", " - netfilter: nf_conntrack_expect: use expect->helper", "" ], "package": "linux", "version": "5.15.0-187.197", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2160896, 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 15:36:42 +0200" } ], "notes": "linux-headers-5.15.0-187 version '5.15.0-187.197' (source package linux version '5.15.0-187.197') was added. linux-headers-5.15.0-187 version '5.15.0-187.197' has the same source package name, linux, as removed package linux-headers-5.15.0-186. As such we can use the source package version of the removed package, '5.15.0-186.196', 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-5.15.0-187-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-187.197", "version": "5.15.0-187.197" }, "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2160896, 1786013 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-187.197 -proposed tracker (LP: #2160896)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] update annotations scripts", " - [Packaging] resync retpoline extraction", "", " * CVE-2026-53086", " - net: bcmgenet: fix racing timeout handler", "", " * CVE-2026-53225", " - sctp: fix uninit-value in __sctp_rcv_asconf_lookup()", "", " * CVE-2026-53228", " - ipv6: sit: reload inner IPv6 header after GSO offloads", "", " * CVE-2026-43499", " - rtmutex: Use waiter::task instead of current in remove_waiter()", "", " * CVE-2026-46331", " - net/sched: fix pedit partial COW leading to page cache corruption", "", " * CVE-2026-53212", " - netfilter: nft_tunnel: fix use-after-free on object destroy", "", " * CVE-2026-53359", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", "", " * CVE-2026-52989", " - nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers", "", " * CVE-2026-52924", " - sctp: purge outqueue on stale COOKIE-ECHO handling", "", " * CVE-2026-43378", " - smb: server: fix use-after-free in smb2_open()", "", " * CVE-2025-27558", " - wifi: prevent A-MSDU attacks in mesh networks", "", " * CVE-2026-53215", " - net: mvpp2: refill RX buffers before XDP or skb use", "", " * CVE-2026-53176", " - IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN", "", " * CVE-2026-46266", " - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP", "", " * CVE-2026-43198", " - tcp: fix potential race in tcp_v6_syn_recv_sock()", "", " * CVE-2026-31705", " - ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment", "", " * CVE-2026-31448", " - ext4: avoid infinite loops caused by residual data", "", " * CVE-2026-31414", " - netfilter: nf_conntrack_expect: use expect->helper", "" ], "package": "linux", "version": "5.15.0-187.197", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2160896, 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 15:36:42 +0200" } ], "notes": "linux-headers-5.15.0-187-generic version '5.15.0-187.197' (source package linux version '5.15.0-187.197') was added. linux-headers-5.15.0-187-generic version '5.15.0-187.197' has the same source package name, linux, as removed package linux-headers-5.15.0-186. As such we can use the source package version of the removed package, '5.15.0-186.196', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-5.15.0-187-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-186.196", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-187.197", "version": "5.15.0-187.197" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-187.197", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "5.15.0-187.197", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 18:50:39 +0200" } ], "notes": "linux-image-5.15.0-187-generic version '5.15.0-187.197' (source package linux-signed version '5.15.0-187.197') was added. linux-image-5.15.0-187-generic version '5.15.0-187.197' has the same source package name, linux-signed, as removed package linux-image-5.15.0-186-generic. As such we can use the source package version of the removed package, '5.15.0-186.196', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-187-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "5.15.0-187.197", "version": "5.15.0-187.197" }, "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2160896, 1786013 ], "changes": [ { "cves": [ { "cve": "CVE-2026-53086", "url": "https://ubuntu.com/security/CVE-2026-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53225", "url": "https://ubuntu.com/security/CVE-2026-53225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 (\"net: sctp: fix KMSAN uninit-value in sctp_inq_pop\").", "cve_priority": "negligible", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53228", "url": "https://ubuntu.com/security/CVE-2026-53228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-43499", "url": "https://ubuntu.com/security/CVE-2026-43499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the \tchangelog ]", "cve_priority": "high", "cve_public_date": "2026-05-21 13:16:00 UTC" }, { "cve": "CVE-2026-46331", "url": "https://ubuntu.com/security/CVE-2026-46331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.", "cve_priority": "high", "cve_public_date": "2026-06-16 08:16:00 UTC" }, { "cve": "CVE-2026-53212", "url": "https://ubuntu.com/security/CVE-2026-53212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53359", "url": "https://ubuntu.com/security/CVE-2026-53359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad (\"KVM: x86: Fix shadow paging use-after-free due to unexpected GFN\") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-52989", "url": "https://ubuntu.com/security/CVE-2026-52989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.", "cve_priority": "critical", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52924", "url": "https://ubuntu.com/security/CVE-2026-52924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In this path, the outbound stream scheduler state (stream->out_curr) is expected to be clean, since no user data should have been transmitted yet unless the state machine has already partially progressed. However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a Stale Cookie ERROR is received, the association is rolled back from COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already have been queued and even bundled with the COOKIE-ECHO chunk. During the rollback, sctp_stream_update() frees the old stream table and installs a new one, but it does not invalidate stream->out_curr. As a result, out_curr may still point to a freed sctp_stream_out entry from the previous stream state. Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on stream->out_curr->ext, which can lead to use-after-free once the old stream state has been released via sctp_stream_free(). This results in crashes such as (reported by Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Fix this by fully purging the association outqueue when handling the Stale Cookie case. This ensures all pending transmit and retransmit state is dropped, and any scheduler cached pointers are invalidated, making it safe to rebuild stream state during COOKIE_WAIT restart. Updating only stream->out_curr would be insufficient, since queued and retransmittable data would still reference the old stream state and trigger later use-after-free in dequeue paths.", "cve_priority": "high", "cve_public_date": "2026-06-24 08: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-2025-27558", "url": "https://ubuntu.com/security/CVE-2025-27558", "cve_description": "IEEE P802.11-REVme D1.1 through D7.0 allows FragAttacks against mesh networks. In mesh networks using Wi-Fi Protected Access (WPA, WPA2, or WPA3) or Wired Equivalent Privacy (WEP), an adversary can exploit this vulnerability to inject arbitrary frames towards devices that support receiving non-SSP A-MSDU frames. NOTE: this issue exists because of an incorrect fix for CVE-2020-24588. P802.11-REVme, as of early 2025, is a planned release of the 802.11 standard.", "cve_priority": "medium", "cve_public_date": "2025-05-21 19:16:00 UTC" }, { "cve": "CVE-2026-53215", "url": "https://ubuntu.com/security/CVE-2026-53215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.", "cve_priority": "critical", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53176", "url": "https://ubuntu.com/security/CVE-2026-53176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.", "cve_priority": "high", "cve_public_date": "2026-06-25 09: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-43198", "url": "https://ubuntu.com/security/CVE-2026-43198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix potential race in tcp_v6_syn_recv_sock() Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late. After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it. Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found. Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion. This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.", "cve_priority": "high", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-31705", "url": "https://ubuntu.com/security/CVE-2026-31705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buf_free_len is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space. When the EA value exactly fills the remaining buffer (buf_free_len == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buf_free_len boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERY_INFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory. Add a bounds check before the alignment memset to ensure buf_free_len can accommodate the padding bytes. This is the same bug pattern fixed by commit beef2634f81f (\"ksmbd: fix potencial OOB in get_file_all_info() for compound requests\") and commit fda9522ed6af (\"ksmbd: fix OOB write in QUERY_INFO for compound requests\"), both of which added bounds checks before unconditional writes in QUERY_INFO response handlers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-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-31414", "url": "https://ubuntu.com/security/CVE-2026-31414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.", "cve_priority": "high", "cve_public_date": "2026-04-13 14:16:00 UTC" } ], "log": [ "", " * jammy/linux: 5.15.0-187.197 -proposed tracker (LP: #2160896)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] update annotations scripts", " - [Packaging] resync retpoline extraction", "", " * CVE-2026-53086", " - net: bcmgenet: fix racing timeout handler", "", " * CVE-2026-53225", " - sctp: fix uninit-value in __sctp_rcv_asconf_lookup()", "", " * CVE-2026-53228", " - ipv6: sit: reload inner IPv6 header after GSO offloads", "", " * CVE-2026-43499", " - rtmutex: Use waiter::task instead of current in remove_waiter()", "", " * CVE-2026-46331", " - net/sched: fix pedit partial COW leading to page cache corruption", "", " * CVE-2026-53212", " - netfilter: nft_tunnel: fix use-after-free on object destroy", "", " * CVE-2026-53359", " - KVM: x86: Fix shadow paging use-after-free due to unexpected role", "", " * CVE-2026-52989", " - nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers", "", " * CVE-2026-52924", " - sctp: purge outqueue on stale COOKIE-ECHO handling", "", " * CVE-2026-43378", " - smb: server: fix use-after-free in smb2_open()", "", " * CVE-2025-27558", " - wifi: prevent A-MSDU attacks in mesh networks", "", " * CVE-2026-53215", " - net: mvpp2: refill RX buffers before XDP or skb use", "", " * CVE-2026-53176", " - IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN", "", " * CVE-2026-46266", " - inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP", "", " * CVE-2026-43198", " - tcp: fix potential race in tcp_v6_syn_recv_sock()", "", " * CVE-2026-31705", " - ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment", "", " * CVE-2026-31448", " - ext4: avoid infinite loops caused by residual data", "", " * CVE-2026-31414", " - netfilter: nf_conntrack_expect: use expect->helper", "" ], "package": "linux", "version": "5.15.0-187.197", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2160896, 1786013 ], "author": "Manuel Diewald ", "date": "Fri, 17 Jul 2026 15:36:42 +0200" } ], "notes": "linux-modules-5.15.0-187-generic version '5.15.0-187.197' (source package linux version '5.15.0-187.197') was added. linux-modules-5.15.0-187-generic version '5.15.0-187.197' has the same source package name, linux, as removed package linux-headers-5.15.0-186. As such we can use the source package version of the removed package, '5.15.0-186.196', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-186", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": "5.15.0-186.196" }, "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-5.15.0-186-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": "5.15.0-186.196" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-5.15.0-186-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "5.15.0-186.196", "version": "5.15.0-186.196" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-186-generic", "from_version": { "source_package_name": "linux", "source_package_version": "5.15.0-186.196", "version": "5.15.0-186.196" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 22.04 jammy image from daily image serial 20260802 to 20260807", "from_series": "jammy", "to_series": "jammy", "from_serial": "20260802", "to_serial": "20260807", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }