{"id":"OESA-2026-3708","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nseg6: separate dst_cache for input and output paths in seg6 lwtunnel\n\nThe seg6 lwtunnel uses a single dst_cache per encap route, shared\nbetween seg6_input_core() and seg6_output_core(). These two paths\ncan perform the post-encap SID lookup in different routing contexts\n(e.g., ip rules matching on the ingress interface, or VRF table\nseparation). Whichever path runs first populates the cache, and the\nother reuses it blindly, bypassing its own lookup.\n\nFix this by splitting the cache into cache_input and cache_output,\nso each path maintains its own cached dst independently.(CVE-2026-31668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE\n\nThe current implementation incorrectly handles memory regions (MRs) with\npage sizes different from the system PAGE_SIZE. The core issue is that\nrxe_set_page() is called with mr->page_size step increments, but the\npage_list stores individual struct page pointers, each representing\nPAGE_SIZE of memory.\n\nib_sg_to_page() has ensured that when i>=1 either\na) SG[i-1].dma_end and SG[i].dma_addr are contiguous\nor\nb) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned.\n\nThis leads to incorrect iova-to-va conversion in scenarios:\n\n1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K):\n   ibmr->iova = 0x181800\n   sg[0]: dma_addr=0x181800, len=0x800\n   sg[1]: dma_addr=0x173000, len=0x1000\n\n   Access iova = 0x181800 + 0x810 = 0x182010\n   Expected VA: 0x173010 (second SG, offset 0x10)\n   Before fix:\n     - index = (0x182010 >> 12) - (0x181800 >> 12) = 1\n     - page_offset = 0x182010 & 0xFFF = 0x10\n     - xarray[1] stores system page base 0x170000\n     - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)\n\n2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K):\n   ibmr->iova = 0x18f800\n   sg[0]: dma_addr=0x18f800, len=0x800\n   sg[1]: dma_addr=0x170000, len=0x1000\n\n   Access iova = 0x18f800 + 0x810 = 0x190010\n   Expected VA: 0x170010 (second SG, offset 0x10)\n   Before fix:\n     - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1\n     - page_offset = 0x190010 & 0xFFFF = 0x10\n     - xarray[1] stores system page for dma_addr 0x170000\n     - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)\n\nYi Zhang reported a kernel panic[1] years ago related to this defect.\n\nSolution:\n1. Replace xarray with pre-allocated rxe_mr_page array for sequential\n   indexing (all MR page indices are contiguous)\n2. Each rxe_mr_page stores both struct page* and offset within the\n   system page\n3. Handle MR page_size != PAGE_SIZE relationships:\n   - page_size > PAGE_SIZE: Split MR pages into multiple system pages\n   - page_size <= PAGE_SIZE: Store offset within system page\n4. Add boundary checks and compatibility validation\n\nThis ensures correct iova-to-va conversion regardless of MR page size\nand system PAGE_SIZE relationship, while improving performance through\narray-based sequential access.\n\nTests on 4K and 64K PAGE_SIZE hosts:\n- rdma-core/pytests\n  $ ./build/bin/run_tests.py  --dev eth0_rxe\n- blktest:\n  $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd\n\n[1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/(CVE-2026-46325)\n\nIn the Linux kernel, compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when user_regset_copyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's pt_regs, corrupting its register state and potentially leaking kernel stack contents. compat_restore_sigcontext() has the same issue: it calls cregs_to_regs() even when __copy_from_user() fails, leading to the same corruption of the signal-returning task's register state on error.(CVE-2026-64082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: Take a long-lived file reference at submit\n\nhandshake_nl_accept_doit() needs the file pointer backing\nreq->hr_sk->sk_socket to survive the window between\nhandshake_req_next() and the subsequent FD_PREPARE() and get_file().\nThe submit-side sock_hold() does not provide that.  sk_refcnt keeps\nstruct sock alive, but struct socket is owned by sock->file: when\nthe consumer fputs the last file reference, sock_release() tears\nthe socket down regardless of any sock_hold.\n\nAdd an hr_file pointer to struct handshake_req and acquire an\nexplicit reference on sock->file during handshake_req_submit().\nhandshake_complete() and handshake_req_cancel() release the\nreference on the completion-bit-winning path.\n\nThe submit error path must also release the file reference, but\nafter rhashtable insertion a concurrent handshake_req_cancel() can\ndiscover the request and race the error path.  Gate the error-path\ncleanup -- sk_destruct restoration, fput, and request destruction\n-- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same\nserialization handshake_complete() and handshake_req_cancel()\nalready use.  When cancel has already claimed ownership, the submit\nerror path returns without touching the request; socket teardown\nhandles final destruction.\n\nThe accept-side dereferences are not yet retargeted; that change\ncomes in the next patch.(CVE-2026-64523)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix two unsafe bare decodes in decode_lockers()\n\ndecode_lockers() in cls_lock_client.c contains two bare decode operations\nthat allow a malicious or compromised OSD to trigger slab-out-of-bounds\nreads:\n\n1. ceph_decode_32(p) at the num_lockers field has no preceding bounds\n   check. ceph_start_decoding() accepts struct_len=0 as valid -- the\n   internal ceph_decode_need(p, end, 0, bad) always passes -- so when an\n   OSD sends struct_len=0, ceph_start_decoding() returns success with\n   p == end. The immediately following bare ceph_decode_32(p) then reads\n   4 bytes past the validated buffer boundary. The garbage value is\n   passed directly to kzalloc_objs() as the locker count.\n\n   The sibling function decode_watchers() in osd_client.c already uses\n   ceph_decode_32_safe() after its own ceph_start_decoding() call.\n   decode_lockers() was the only site using the bare variant.\n\n2. ceph_decode_8(p) after the decode_locker() loop has no preceding\n   bounds check. If an OSD crafts num_lockers such that the loop\n   advances p exactly to end, the subsequent bare ceph_decode_8(p) reads\n   one byte past the validated buffer boundary. The result is passed\n   directly into *type, which is used as a lock type discriminator by\n   callers, giving an OSD-controlled one-byte OOB read with direct\n   influence over the lock type field.\n\nFix both by replacing bare operations with their safe variants:\n  ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers,\n                                           err_inval)\n  ceph_decode_8(p)  -> ceph_decode_8_safe(p, end, *type,\n                                          err_free_lockers)\n\nThe goto targets differ intentionally:\n  err_inval: is a new label returning -EINVAL directly. It is used for\n  the pre-allocation failure path where *lockers is not yet allocated\n  and must not be passed to ceph_free_lockers().\n\n  err_free_lockers: is the existing label. It is used for the\n  post-allocation failure path where *lockers is allocated and must\n  be freed.\n\nret is set to -EINVAL before ceph_decode_8_safe() so that\nerr_free_lockers returns the correct error code on bounds violation.\nWithout this, err_free_lockers would return a stale ret value (0 from\nthe successful decode_locker() loop), silently swallowing the error.\n\n-EINVAL is correct for both failure paths. The data received from the\nOSD is structurally malformed. -ENOMEM would misrepresent the failure\nclass to callers and to stable@ backporters triaging error paths.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment can trigger this against any kernel client that issues the\nlock.get_info class method (e.g. during RBD exclusive lock acquisition).\n\n[ idryomov: trim changelog, formatting ](CVE-2026-68082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: fix double aggregation of flush-marked skbs\n\nCommit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO\npacket.") added a flush check to skb_gro_receive(), but\nskb_gro_receive_list() lacks the same validation.\n\nAs a result, packets marked with NAPI_GRO_CB(skb)->flush may still be\nre-aggregated.\n\nThis allows already-GRO'd packets with existing frag_list to be\nre-aggregated into a new GRO session, corrupting the frag_list chain\nstructure. When skb_segment() attempts to unpack these malformed packets,\nit encounters invalid state and triggers a kernel panic.\n\nScenario (Tethering/Device forwarding):\n  1. Driver: Generated aggregated packet P1 via LRO with frag_list\n  2. Dev A: Receives aggregated fraglist packet and flush flag set\n  3. Dev A: Re-enters GRO, skb_gro_receive_list() is called\n  4. Missing flush check allows re-aggregation despite flush flag\n  5. Frag_list chain becomes corrupted (loops or dangling refs)\n  6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list\n\nRoot cause in skb_segment():\n  The check at line ~4891:\n    if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) &&\n        (skb_headlen(list_skb) == len || sg)) {\n\n  When frag_list is corrupted by double aggregation, when list_skb is\n  a NULL pointer from skb->next, skb_headlen(list_skb) dereference\n  NULL/corrupted pointers occurs.\n\nCall Trace:\n skb_headlen(NULL skb)\n skb_segment\n tcp_gso_segment\n tcp4_gso_segment\n inet_gso_segment\n skb_mac_gso_segment\n __skb_gso_segment\n skb_gso_segment\n validate_xmit_skb\n validate_xmit_skb_list\n sch_direct_xmit\n qdisc_restart\n __qdisc_run\n qdisc_run\n net_tx_action\n\nFix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in\nskb_gro_receive_list(), matching the defensive programming pattern of\nskb_gro_receive().(CVE-2026-68136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE\n\n__decode_pg_temp() decodes an user-controlled length but only rejects\nvalues large enough to overflow the allocation; it does not bound it to\nCEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and\napply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size\non-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends\nan OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack\nout-of-bounds write.\n\nAn OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer\nentries at decode time. The bound is well below the old overflow threshold, so\nit also covers the allocation-size overflow the previous check guarded against.\n\n  BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds\n  Write of size 4 ... by task exploit\n   kasan_report (mm/kasan/report.c:595)\n   ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833)\n   calc_target (net/ceph/osd_client.c:1638)\n   __submit_request (net/ceph/osd_client.c:2394)\n   ceph_osdc_start_request (net/ceph/osd_client.c:2490)\n   ceph_osdc_call (net/ceph/osd_client.c:5164)\n   rbd_dev_image_probe (drivers/block/rbd.c:6899)\n   do_rbd_add (drivers/block/rbd.c:7138)\n   ...\n  kernel BUG at net/ceph/osdmap.c:2670!\n\n[ idryomov: do the same in __decode_pg_upmap_items() ](CVE-2026-68159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()\n\nThe v4l2 helper v4l2_async_register_subdev_sensor() calls\nv4l2_async_register_subdev(), which is a macro that expands to\n__v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded\ninside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module\nrather than the sensor driver module that originally set sd->owner. When\nv4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then\noverwrites the sensor driver's owner with NULL.\n\nThis causes the problem that the sensor module's reference count is never\nincremented during async registration, so the module can be removed while\nthe subdevice is still in use by a notifier (e.g., a CSI-2 receiver\nbridge driver).\n\nFix this by renaming v4l2_async_register_subdev_sensor() to\n__v4l2_async_register_subdev_sensor() with an added explicit module\nargument and introducing a wrapper macro:\n    #define v4l2_async_register_subdev_sensor(sd) \\\n        __v4l2_async_register_subdev_sensor(sd, THIS_MODULE)\n\nThis ensures the sensor driver module is properly referenced even when\nthe sensor driver does not init the owner field before calling\nv4l2_async_register_subdev_sensor() and prevents premature module removal.(CVE-2026-68205)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix stale skb->prev after async crypto steals a GSO segment\n\nskb_gso_segment() leaves the segment list head with ->prev pointing at\nthe last segment, an invariant validate_xmit_skb_list() relies on when\nit sets its tail pointer (tail = skb->prev).\n\nWhen validate_xmit_xfrm() walks a GSO list and some segments are stolen\nby async crypto (->xmit() returns -EINPROGRESS), those segments are\nunlinked from the list but the head ->prev is never updated.  If the\nlast segment is the one stolen, the returned head still has ->prev\npointing at it, even though it is now owned by the crypto engine and may\nbe freed.  validate_xmit_skb_list() later does tail->next = skb, writing\nthrough that stale pointer -- a use-after-free.\n\nRepoint skb->prev at the last retained segment before returning.(CVE-2026-68426)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ieee80211: validate MLE common info length\n\nieee80211_mle_common_size() uses the first common-info octet as the\ncommon information length for all known MLE types. However,\nieee80211_mle_size_ok() only validates that octet for Basic, Probe\nRequest, and TDLS MLEs.\n\nReconfiguration MLEs also skipped the length octet when calculating the\nminimum common size, and Priority Access MLEs skipped validation of the\nadvertised common information length.\n\nAccount for the Reconfiguration common-info length octet and validate\nthe advertised common information length for all known MLE types. Keep\nunknown-type handling unchanged.\n\n[remove now misleading comment](CVE-2026-68471)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reset register bounds before narrowing retval range in check_mem_access()\n\nWhen the BPF verifier processes a context load of an LSM hook return\nvalue, it calls __mark_reg_s32_range() to narrow the register to the\nhook's valid range. However, __mark_reg_s32_range() intersects the new\nrange with the register's existing bounds using max_t()/min_t() rather\nthan replacing them.\n\nIf the destination register carries stale bounds from a prior instruction\n(e.g. BPF_MOV64_IMM), the intersection can produce a range narrower than\nreality. The verifier then believes it knows the register's exact value,\nwhile at runtime the actual hook return value is loaded, creating a\nverifier/runtime mismatch that can be used to bypass BPF memory safety\nchecks.\n\nThe else branch already calls mark_reg_unknown() to reset register state\nbefore any narrowing. Apply the same reset in the is_retval path so\nstale bounds are cleared before __mark_reg_s32_range() intersects.(CVE-2026-72111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch\n\nIn alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd\nand non-rsvd hugetlb cgroup charges.  When map_chg is set,\nhugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but\nthe immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg\nwith the non-rsvd cgroup pointer.\n\nAs a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong\n(non-rsvd) cgroup pointer into the folio's rsvd slot.\n\nWhen the folio is later freed, free_huge_folio() unconditionally calls\nboth hugetlb_cgroup_uncharge_folio() and\nhugetlb_cgroup_uncharge_folio_rsvd().  The rsvd uncharge reads back the\nwrong cgroup from the folio and decrements a counter that was never\ncharged for that cgroup, causing a page_counter underflow:\n\n  page_counter underflow: -512 nr_pages=512\n  WARNING: mm/page_counter.c:61 at page_counter_cancel\n\nFix this by introducing a separate h_cg_rsvd pointer exclusively for the\nrsvd charge path, keeping the rsvd and non-rsvd charges fully independent\nthrough their charge, commit, and error uncharge paths.(CVE-2026-72213)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling\n\nHyunwoo Kim reports some really bad races should the following\nsituation occur:\n\n- LPI-I is pending in vcpu-B's AP list\n- vcpu-A writes to vcpu-B's RD to disable its LPIs\n- vcpu-C moves I from B to C\n\nIf the last two race nicely enough, vgic_prune_ap_list() can drop\nthe irq and AP list locks, reacquire them, and in the interval\nthe irq has been freed. UAF follows.\n\nThe fix is two-fold:\n\n- Before dropping the irq and ap_list locks, take a reference on\n  the irq\n\n- Do not try to handle migration of the pending bit: there is no\n  expectation that this state is retained, as per the architecture\n\nWith that, we're sure that the interrupt is still around, and we\nsafely remove it from the AP list as it has no target at this\nstage (unless another interrupt fires, but that's another story).(CVE-2026-72288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()\n\nFunction kvm_vcpu_ioctl_interrupt() can be called from userspace, here\nadd irq validility cheking in kvm_vcpu_ioctl_interrupt().(CVE-2026-72294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()\n\nWhen a timer is deleted and not re-armed in igmp_mod_timer(), or stopped\nin igmp_stop_timer(), the code currently decrements the reference counter\nof the multicast list entry @im using refcount_dec(&im->refcnt).\n\nHowever, both functions can be called from the RCU reader path:\n- igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu()\n- igmp_stop_timer() via igmp_rcv() -> igmp_heard_report()\n\nIf the group im was concurrently removed from the list by ip_mc_dec_group(),\nits reference count might have already been decremented to 1.\n\nIn this case, timer_delete() succeeds, and refcount_dec() decrements\nthe refcount from 1 to 0. Since refcount_dec() does not free the object\nwhen it hits 0 (unlike ip_ma_put()), the im structure is leaked.\n\nFix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt),\nand deferring the put until after the spinlock is released.(CVE-2026-72321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/liquidio: drop cached VF pci_dev LUT\n\nThe PF SR-IOV enable path caches VF pci_dev pointers in\ndpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those\nentries do not own a reference, because the iterator drops the previous\ndevice reference on each step. The cached pointer is then dereferenced\nlater when handling OCTEON_VF_FLR_REQUEST.\n\nReplace the cached VF mapping with runtime lookup on the mailbox DPI\nring: derive the VF index from q_no, resolve the VF via exported PCI\nIOV helpers, validate it with the PF pointer and VF ID, then issue\npcie_flr() and drop the reference with pci_dev_put(). Remove the\nunused VF lookup table initialization and cleanup.(CVE-2026-72329)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: add INIT verification after cookie unpacking\n\nIn SCTP handshake, the INIT chunk is initially processed by the server\nand embedded into the cookie carried in INIT-ACK. The client then\nreturns this cookie via COOKIE-ECHO, where the server unpacks it and\nreconstructs the original INIT chunk.\n\nWhen cookie authentication is enabled, the cookie contents are protected\nagainst tampering, so reusing the unpacked INIT without re-verification\nis safe.\n\nHowever, when cookie authentication is disabled, the reconstructed INIT\ncan no longer be trusted. In this case, the INIT must be explicitly\nvalidated after unpacking to avoid processing potentially tampered data.\n\nAdd sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO\nprocessing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook())\nwhen cookie_auth_enable is disabled. On failure, the new association is\nfreed and the packet is discarded.\n\nAlso tighten cookie validation in sctp_unpack_cookie() by verifying the\nembedded chunk type is SCTP_CID_INIT before treating it as an INIT\nchunk.\n\nFinally, update sctp_verify_init() to validate parameter bounds using\nthe actual embedded INIT length instead of chunk->chunk_end, since the\nINIT stored in COOKIE-ECHO may not span the entire chunk buffer.(CVE-2026-72398)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy()\n\nTIPC UDP media bearer teardown calls dst_cache_destroy() on its\nreplicast caches before calling synchronize_net() to wait for\nconcurrent RCU readers (transmitters) to finish:\n\nstatic void cleanup_bearer(struct work_struct *work)\n{\n...\n\tlist_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {\n\t\tdst_cache_destroy(&rcast->dst_cache);\n\t\tlist_del_rcu(&rcast->list);\n\t\tkfree_rcu(rcast, rcu);\n\t}\n...\n\tdst_cache_destroy(&ub->rcast.dst_cache);\n\tudp_tunnel_sock_release(ub->sk);\n\tsynchronize_net();\n...\n}\n\nThis is highly buggy because dst_cache_destroy() immediately frees the\nper-CPU cache memory (free_percpu()) and releases the cached dst\nentries without any synchronization.\n\nIf a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another\nCPU under RCU protection, it can call dst_cache_get() concurrently,\nleading to:\n1. Use-After-Free on the per-CPU cache pointer itself (crash).\n2. "rcuref - imbalanced put()" warning if it attempts to release a\n   dst that was concurrently released by dst_cache_destroy().\n\nFurthermore, calling kfree(ub) immediately after synchronize_net() without\nclosing the socket first (or waiting after closing it) leaves a window\nwhere a concurrent receiver (tipc_udp_recv()) could start after\nsynchronize_net(), access ub, and suffer a UAF when kfree(ub) runs.\n\nTo fix this, we must defer dst_cache_destroy() and kfree(ub) until after\nwe have ensured that no more readers can see the bearer/socket and all\nexisting readers have finished:\n\n1. Defer rcast entry destruction (both dst_cache_destroy() and kfree())\n   to an RCU callback using call_rcu_hurry().\n   Using call_rcu_hurry() ensures the dst entries are released quickly.\n\n2. Release the bearer socket using udp_tunnel_sock_release() (stops\n   new receive readers).\n\n3. Call synchronize_net() to wait for all outstanding RCU readers\n   (both transmit and receive) to finish.\n\n4. Now that it is safe, call dst_cache_destroy() on the main bearer\n   cache, and free ub.\n\nNote: 3) and 4) can be changed later in net-next to also use\ncall_rcu_hurry() and get rid of the synchronize_net() latency.(CVE-2026-72404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync\n\nYue Sun reported a use-after-free and debugobjects warning in\nudp_tunnel_nic_device_sync_work() during concurrent device operations.\n\nThe workqueue core clears the internal pending bit before invoking the\nworker. At that point, a concurrent thread can queue the work again.\nWhen the already running worker eventually clears the work_pending flag\nto 0, it mistakenly clears the flag for the newly queued instance.\nudp_tunnel_nic_unregister() then observes work_pending as 0 and frees\nthe structure while the second work item is still active in the queue,\nleading to UAF.\n\nFix this by returning early in udp_tunnel_nic_device_sync() if\nwork_pending is already set, preventing redundant work queueing.(CVE-2026-72405)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Guard conntrack opts error writes\n\nThe conntrack lookup and allocation kfuncs take an opts pointer\ntogether with an opts__sz argument. The verifier checks only the memory\nrange described by opts__sz, but the wrappers unconditionally write\nopts->error whenever the internal lookup or allocation helper returns an\nerror.\n\nFor an invalid size smaller than the end of opts->error, that write can\nland outside the verifier-checked range. Keep returning NULL for invalid\narguments, but only report the error through opts->error when the\nsupplied size includes the field.\n\nThis preserves error reporting for the supported 12-byte and 16-byte\nlayouts, and for other invalid sizes that still include opts->error.(CVE-2026-72423)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix UAF in hci_unregister_dev()\n\nhci_unregister_dev() does not disable cmd_timer and ncmd_timer\nbefore the hci_dev structure is freed. If a timeout fires\nduring device teardown, the callback dereferences freed memory\n(including the hdev->reset function pointer), leading to a\nuse-after-free.\n\nAdd disable_delayed_work_sync() calls alongside the existing\ndisable_work_sync() calls to ensure both timers are fully\nquiesced before teardown proceeds.(CVE-2026-74302)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbe: do not configure xps for XDP queues\n\nnetif_set_xps_queue() should not be called for an XDP Tx queue, since such\nqueues are not netdev-exposed. On systems with number of CPUs >=64, on E610\nadapter, netdev is configured with maximum number queue pairs being 63\n(due to MSI-X assignment), but configuring XDP results in 64 XDP queues.\n\nSo, during XDP program load, when netif_set_xps_queue() is called for the\nlast XDP queue, we get a WARNING with a call trace and KASAN report\nafterwards (if enabled).\n\n[ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668\n[...]\n[ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40\n[ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84\n[ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246\n[ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000\n[ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488\n[ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000\n[ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8\n[ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8\n[ 2012.700065] FS:  00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000\n[ 2012.700069] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0\n[ 2012.700077] PKRU: 55555554\n[ 2012.700080] Call Trace:\n[ 2012.700084]  <TASK>\n[ 2012.700087]  ? ktime_get+0x61/0x150\n[ 2012.700097]  ? usleep_range_state+0x133/0x1b0\n[ 2012.700108]  ? __pfx_usleep_range_state+0x10/0x10\n[ 2012.700114]  netif_set_xps_queue+0x31/0x50\n[ 2012.700119]  ixgbe_configure_tx_ring+0x472/0x920 [ixgbe]\n[...]\n[ 2012.700486]  ixgbe_xdp+0x38f/0x750 [ixgbe]\n\n[...]\n\n[ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40\n[ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668\n\nSkip XPS configuration for XDP Tx queues.(CVE-2026-74317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix page fragment cache leak in error path\n\nIn nvmet_tcp_alloc_queue(), when a connection is closed during the\nallocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN),\nthe error handling jumps to out_destroy_sq and then to out_ida_remove\nwithout draining the page fragment cache.\n\nAlthough nvmet_tcp_free_cmd() is called in some error paths to release\nindividual page fragments, the underlying page cache reference held by\nqueue->pf_cache is never released. The first allocation using pf_cache\nis the call to nvmet_tcp_alloc_cmd() for queue->connect, which happens\nafter ida_alloc() returns successfully. This results in a page leak each\ntime a connection fails during allocation, which could lead to memory\nexhaustion over time if connections are repeatedly opened and closed.\n\nFix this by calling page_frag_cache_drain() before freeing the queue\nstructure in the out_ida_remove label.(CVE-2026-74386)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down scalable-mode context entry\n\ndevice_pasid_table_teardown() zeroes the 128-bit scalable-mode context\nentry with context_clear_entry() while the Present bit is still set. This\ncreates a window where the hardware can fetch a torn entry, with some\nfields already zeroed while Present is still set, leading to unpredictable\nbehavior or spurious faults. The context-cache invalidation is issued only\nafter the entry has been zeroed, and intel_pasid_free_table() then frees\nthe PASID directory pages, so the IOMMU can keep walking a stale Present=1\nentry that points at freed memory.\n\nWhile x86 provides strong write ordering, the compiler may reorder the two\n64-bit writes to the entry, and the hardware fetch is not guaranteed to be\natomic with respect to multiple CPU writes.\n\nCommit c1e4f1dccbe9d ("iommu/vt-d: Clear Present bit before tearing down\ncontext entry") fixed this exact pattern in domain_context_clear_one() and\nthe copied-context path, but device_pasid_table_teardown() was not\nconverted.\n\nAlign it with the "Guidance to Software for Invalidations" in the VT-d\nspec, Section 6.5.3.3, using the same ownership handshake as the sibling\nfix: clear only the Present bit, flush it to the IOMMU, perform the\ncontext-cache invalidation, and only then zero the rest of the entry.(CVE-2026-74439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: use pskb_network_may_pull() in route_shortcircuit()\n\nroute_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr))\n(or ipv6hdr), which checks if bytes are available starting from skb->data.\n\nHowever, in vxlan_xmit(), skb->data points to the MAC header, so\nskb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20)\nonly checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of\nIP header), leaving the rest of the IP header potentially un-pulled in non-linear\nfrags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled\nlinear buffer length.\n\nFix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to\nthe length check to ensure the full network header is present in the linear buffer.(CVE-2026-74473)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: use neigh_ha_snapshot() in route_shortcircuit()\n\nThe neighbour hardware address n->ha can be updated asynchronously by the\nneighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without\nholding the seqlock loop can lead to torn reads or reading a partially updated\nMAC address.\n\nUse neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under\nread_seqbegin()/read_seqretry() lock protection before using it.\n\nNote that arp_reduce() and neigh_reduce() seem to have the same issue\nleft for future patches.(CVE-2026-74475)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nveth: convert frag_list skbs before running XDP\n\nA frag_list skb can reach veth with data_len set but nr_frags zero.\nveth_convert_skb_to_xdp_buff() only converts skbs that are shared,\nlocked, have frags[], or do not have enough headroom. It later uses\nskb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and\nxdp_frags_size.\n\nThat exposes frag_list data to XDP as if it were stored in frags[], but\nfrags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment\nmetadata, walk an empty fragment entry, and crash in memcpy() from\n__xsk_rcv().\n\nRoute non-linear skbs through skb_pp_cow_data() before exposing them to\nXDP, and only advertise XDP frags when the resulting skb has frags[].\nskb_copy_bits() already handles frag_list input, and skb_pp_cow_data()\nbuilds frags[] output with skb_add_rx_frag(), which is the\nrepresentation XDP multi-buffer expects.(CVE-2026-74476)\n\nIn the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend. During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending, page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault.(CVE-2026-74481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: reject a flag character as the field delimiter\n\nThe registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter.\n\nMost fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan.\n\nIf the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character.(CVE-2026-74485)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: restore write access when removing an entry\n\nRegistering an entry with the MISC_FMT_OPEN_FILE flag opens the\ninterpreter via open_exec() which denies write access to it for as\nlong as the entry exists. Removing the entry closes the interpreter\nfile via filp_close() but never restores write access, leaving the\ninode's i_writecount permanently negative. Opening the interpreter\nfor writing keeps failing with ETXTBSY long after the entry is gone\nuntil the inode is evicted from the inode cache.\n\nCommit 90f601b497d7 ("binfmt_misc: restore write access before\nclosing files opened by open_exec()") fixed the same imbalance in the\nerror path of bm_register_write() but the actual removal path has\nbeen leaking the write denial since the introduction of the flag.\n\nRestore write access in put_binfmt_handler() before closing the\ninterpreter file.(CVE-2026-74487)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\\n\\nsnd_usbmidi_akai_output() computes its fill-loop bound\\n\\n\\tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;\\n\\nas a signed int, so a small device-advertised bulk-OUT max_transfer\\nmakes buf_end negative.  The loop guard then compares the u32\\nurb->transfer_buffer_length against that negative int: the usual\\narithmetic conversion turns buf_end into a large unsigned value, so the\\nguard stays true and each iteration keeps appending SysEx framing and\\npayload bytes past the end of the URB transfer buffer, which is only\\nmax_transfer bytes long.\\n\\nA USB device that advertises a tiny bulk-OUT endpoint can therefore\\ntrigger an attacker-length- and content-controlled heap out-of-bounds\\nwrite when a process writes to the created /dev/snd/midiC*D* node.\\n\\nReturn early when there is no room for even one SysEx, so the loop is\\nnever entered with a bound that would wrap.  The loop is the last\\nstatement of the function, so bailing out is equivalent to it not\\nrunning.\\n\\nDiscovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>(CVE-2026-74499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: pci: Fix memory accounting for pinned/unpinned pages\n\nThe account_mem() and unaccount_mem() functions call get_uid() which\nincrements the reference count of struct user_struct on every invocation.\nBut we don't decrement the count by calling free_uid(). It also\naccounted/unaccounted the pages against the current->mm. But its possible\nthe unaccount_mem() can be called from a different process context than the\none that originally pinned the pages.\n\nLet's fix this by storing the pinning process user_struct and mm_struct\nwhen accounting for pinned pages, and subsequently free these resources\nwhen the pages are unpinned.\n\n[(CVE-2026-74514)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: fix leaking sk after socket release\n\niso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket ||\nsock_flag(sk, SOCK_DEAD) for early return, but this is always true since\nsock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket\nalways leaks, iso_sock_destruct is never called.\n\nThe socket reference also leaks when __iso_sock_close() does not set\nSOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after\nzapping.\n\nFix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for\nsomething else, and lock_sock to ensure iso_sock_kill() puts sk only\nafter socket release only once. Release and iso_conn_del may run\nconcurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up\nafter zapping.\n\nRemove call to iso_sock_kill() from iso_sock_close(), as it's generally\nno-op there.(CVE-2026-74536)\n\nIn the Linux kernel, the following vulnerability has been resolved: sctp: clear new_transport when removing a peer. sctp_process_asconf_param() stores a newly added peer transport in asoc->new_transport. After all parameters in the ASCONF chunk have been processed, sctp_sf_do_asconf() uses this pointer to send a HEARTBEAT to the new transport. An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctp_assoc_del_nonprimary_peers(). The removal does not clear asoc->new_transport, leaving it pointing to the removed transport. sctp_sf_do_asconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. After the transport is freed by RCU, a successful ASCONF_ACK for the replacement address releases the queued HEARTBEAT and sctp_outq_select_transport() reads the freed transport's state, leading to a use-after-free condition.(CVE-2026-74586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nsctp: fix use-after-free of cached ASCONF chunk\\n\\naddip_last_asconf caches the outstanding outbound ASCONF chunk. The normal\\nASCONF-ACK completion path releases the chunk and clears the pointer.\\n\\nHowever, sctp_asconf_queue_teardown() releases the cached chunk without\\nclearing addip_last_asconf. During peer restart handling,\\nsctp_sf_do_dupcook_a() queues SCTP_CMD_PURGE_ASCONF_QUEUE, which invokes\\nsctp_asconf_queue_teardown() while the association remains alive and leaves\\nthe pointer dangling.\\n\\nA delayed authenticated ASCONF-ACK can then reach sctp_sf_do_asconf_ack(),\\nwhich accesses the stale chunk and passes it to sctp_process_asconf_ack(),\\ncausing a use-after-free and a second release.\\n\\nClearing the pointer exposes a race with T4 expiry. Peer restart handling\\nqueues the timer stop before the purge, but SCTP_CMD_TIMER_STOP uses\\ntimer_delete(), which does not wait for a callback already running on\\nanother CPU. Such a callback can reach sctp_sf_t4_timer_expire() after\\nthe purge and dereference NULL.\\n\\nClear addip_last_asconf after releasing the cached chunk, and make\\nsctp_sf_t4_timer_expire() consume a stale T4 expiry if no outstanding\\nASCONF remains.(CVE-2026-74587)\n\nIn the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on. __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport. The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. A SACK that reneges on the TSN clears the flag, and the next SACK reaches inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer().(CVE-2026-74588)\n\nIn the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix sk_redir use-after-free in send verdict. sk_psock_msg_verdict() takes a socket reference for psock->sk_redir. tcp_bpf_send_verdict() copies that pointer while holding the source socket lock, but does not take a reference for the local copy before dropping the lock around tcp_bpf_sendmsg_redir(). When apply_bytes keeps the cached verdict active, another sendmsg() on the same source socket can consume the remaining bytes and release the cached reference while the first thread still holds only the raw local pointer, leading to a use-after-free. KASAN reported a slab-use-after-free error.(CVE-2026-74589)\n\nIn the Linux kernel, in __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly, each time modifying xas.xa_index by rounding it down according to the split_order attempted. When a new node is needed but GFP_NOWAIT allocation fails, the lock is dropped, xas_nomem() is used to allocate memory, and the sequence is retried. If the conflict was meanwhile resolved by another thread (e.g., inserting a folio at the same index), the current thread may put the folio into the xarray at an intermediate rounded-down index, causing a race condition. This can lead to rare SIGILLs and SIGSEGVs in production, and triggers the !folio_contains() bug when CONFIG_DEBUG_VM=y is enabled.(CVE-2026-74591)\n\nIn the Linux kernel, the following vulnerability has been resolved: eventfs: Fix use-after-free in eventfs_remove_rec(). eventfs_remove_rec() recursively removes the child at the current loop position. After the recursive call returns, list_for_each_entry() advances by reading list.next from the removed child. If free_ei() drops the final reference, release_ei() reuses the list/rcu union to queue an SRCU callback. The child may be freed before that read. The eventfs_mutex serializes list updates, but it does not keep the removed child alive or prevent the SRCU callback from running.(CVE-2026-74606)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_try_adding_channels(). cifs_try_adding_channels() takes a temporary reference to an interface before dropping iface_lock. If cifs_ses_add_channel() fails, it drops that reference and then increments iface->weight_fulfilled. A concurrent interface list refresh can remove the list reference while channel creation is in progress. In that case, the failure-path kref_put() releases the last reference and frees iface. Updating weight_fulfilled afterward then accesses freed memory.(CVE-2026-74608)\n\nIn the Linux kernel, the following vulnerability has been resolved: tipc: read le->link under the node lock in tipc_node_link_down(). tipc_node_link_down() caches the link pointer before taking n->lock. The delete=true caller frees that very object under n->lock, so the lock does not protect the cached pointer against it. An in-flight CPU that has read l therefore dereferences freed memory once another CPU frees it: a use-after-free read in tipc_link_is_establishing(), and a use-after-free write via tipc_link_reset() on the establishing branch.(CVE-2026-74609)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: don't leave a full plaintext sk_msg ring unpushed\n\nWhen the copy path in tls_sw_sendmsg_locked() adds the fragment that fills the plaintext sk_msg ring, it does not set full_record, so the record is left full and unpushed. A later splice() then adds to an already full ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps onto sg.start and the ring appears empty. Fragments added after that overwrite live entries, and sg.size no longer matches what is reachable between sg.start and sg.end, so pushing the record runs the scatterwalk off the end of the scatterlist.\n\nAn unprivileged user can trigger this on a loopback TCP socket with the "tls" ULP attached:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000008\n  RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0\n  Call Trace:\n   skcipher_walk_next+0x1d1/0x2c0\n   gcm_encrypt_aesni_avx+0x1e9/0x220\n   bpf_exec_tx_verdict+0x3bb/0x860\n   tls_sw_sendmsg+0xa1a/0xca0\n   __sys_sendto+0x1da/0x1f0\n\nSet full_record in the copy path when the ring becomes full, and push a record that is already full on entry to the sendmsg loop.(CVE-2026-74610)\n\nIn the Linux kernel, the following vulnerability has been resolved: tls: rx: restore msg_iter before TLS 1.3 optimistic retry. tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced. The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD.(CVE-2026-74611)\n\nIn the Linux kernel, the veth driver has an skb length accounting error after XDP frag adjustment. veth exposes non-linear skb fragments through an xdp_buff. If an XDP program adjusts the fragment area, veth_xdp_rcv_skb() copies xdp_frags_size back to skb->data_len but leaves skb->len containing the old fragment contribution. After a fragment shrink, this makes skb_headlen() larger than the actual linear area. In the reproduced UDP receive path, __skb_datagram_iter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skb_shared_info. Additionally, bpf_xdp_pull_data() can advance data_end while leaving frags present, and the old __skb_put(skb, off) triggers SKB_LINEAR_ASSERT().(CVE-2026-74612)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nvsock/virtio: read virtqueues under worker locks\\n\\nCommit bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue.\\n\\nRead each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.(CVE-2026-74614)\n\nIn the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down. vxlan_changelink() arms vxlan->age_timer whenever the requested ageing interval differs from the configured one, but there is no netif_running() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timer_delete_sync() in vxlan_stop(), which is .ndo_stop. netif_close_many() drops devices without IFF_UP before __dev_close_many() runs, so that cancel is skipped for such a device. When free_netdev() releases the allocation, the timer lives in freed memory while still queued on a timer_base, causing a use-after-free condition that can lead to system crash or code execution.(CVE-2026-74615)\n\nIn the Linux kernel, the following vulnerability has been resolved: xdp: reject clones that overrun skb_shared_info tailroom. xdpf_clone() clones broadcast copies into a single page and sets frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that page like a normal XDP frame and expects the usual skb_shared_info tailroom at the end of the buffer. The current check only rejects frames whose linear xdp_frame header, headroom, and packet data exceed PAGE_SIZE. A source frame backed by a larger allocation can still satisfy that check while extending into the clone's required shared-info area. When such a clone is converted back into an skb, build_skb_around() places skb_shared_info over live packet bytes and later writes can corrupt XDP return metadata. Reject clones unless their linear area fits inside SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already enforced by the XDP-to-skb conversion path.(CVE-2026-74616)\n\nIn the Linux kernel, an input validation vulnerability exists in the net/sched subsystem. The act_gact and act_police modules lack range checking on the fallback control action. The tcf_action_check_ctrlact() function performs range checking on the primary control action, but act_gact and act_police each carry a second, independent control action supplied by user space (TCA_GACT_PROB.paction and TCA_POLICE_RESULT) that never reaches that helper. User space can set TC_ACT_CONSUMED (TC_ACT_VALUE_MAX + 1), which tells callers the action took ownership of the skb, resulting in memory leaks of sk_buff and its data buffer - one leaked sk_buff per packet traversing the filter.(CVE-2026-74620)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nnet: atlantic: free stranded TX buffers on ring deinit\\n\\naq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good.\\n\\nToday this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and \\"page_pool_release_retry() stalled pool shutdown\\" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load.(CVE-2026-74623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack: defer invalid log until after unlock\n\nTCP and SCTP conntrack paths can emit invalid-packet logs while ct->lock is still held.\n\nWhen invalid logging is routed to nfnetlink_log and conntrack export is enabled, the log path can re-enter conntrack netlink glue and dump the same conntrack again. Protocol attribute dumping may take ct->lock, so logging while holding that lock can deadlock.\n\nDefer the TCP invalid logs by storing only the minimal log context while ct->lock is held and emitting the log after unlocking. Also make the TCP timeout-lowering invalid path return whether a log is needed, then emit that log after unlocking.\n\nDo the same for the SCTP invalid state-transition log that can be reached while ct->lock is held.\n\nAdd a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers that log invalid conntracks while holding ct->lock are caught outside TCP and SCTP as well.(CVE-2026-74624)\n\nIn the Linux kernel, the following vulnerability has been resolved: tracing: Fix race between update_event_fields and event_define_fields. The following sequence may lead to a race between event_define_fields() and update_event_fields(): CPU0 (loads module A) and CPU1 (loads module B) executing concurrently, where access to class->fields is not protected by event_mutex in trace_event_update_all(), leading to a kernel panic. Fix by taking event_mutex in trace_event_update_all() before trace_event_sem.(CVE-2026-74636)\n\nIn the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach. perf_group_detach() handles leader and sibling detach differently. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. This is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. A PERF_IOC_FLAG_GROUP ioctl on the sibling follows the stale group_leader pointer and dereferences the freed leader's context, leading to a use-after-free condition.(CVE-2026-74637)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu(). fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur: CPU 0 (fib_nhc_update_mtu) loads fnhe while CPU 1 (update_or_create_fnhe) holds fnhe_lock, calls fnhe_remove_oldest() to unlink fnhe, and kfree_rcu(fnhe, rcu). CPU 0 then accesses fnhe after grace period, causing a use-after-free. KASAN reported: BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410.(CVE-2026-74656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ebt_nflog: pin the NFLOG backend\n\nnf_log_unregister() runs after the per-net teardown so its final RCU grace period also drains readers that obtained the logger from a per-net binding. However, ebt_nflog passes an explicit ULOG log type to nf_log_packet() without holding a reference on the selected logger module, unlike the xt_NFLOG and nft_log frontends.\n\nAn ebtables nflog rule can therefore remain callable while nfnetlink_log is unloaded. The resulting interleaving causes a use-after-free condition where CPU 1 dereferences per-net state after CPU 0 has freed it.(CVE-2026-74660)\n\nIn the Linux kernel, the following vulnerability has been resolved: inet: frags: publish queues before arming timer. inet_frag_create() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published. The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference. Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inet_frag_kill() can remove the node and balance the hash reference.(CVE-2026-74662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\npacket: synchronize pressure clearing with ring reconfiguration\\n\\npacket_set_ring() updates the RX ring state under sk_receive_queue.lock, but used to publish the tpacket receive mode through po->prot_hook.func after releasing that lock. packet_poll() and packet_recvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage.(CVE-2026-74666)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: reset the MAC header on the packet-socket transmit path\n\npacket_parse_headers() resets the MAC header only for a SOCK_RAW frame whose socket did not bind a protocol. A protocol-bound SOCK_RAW socket, any SOCK_DGRAM frame, and the legacy SOCK_PACKET path therefore leave skb->mac_header unset here.\n\nFor frames sent via __dev_queue_xmit() this is harmless: it resets the MAC header unconditionally. But the packet-socket PACKET_QDISC_BYPASS path uses dev_direct_xmit(), which does not, so the frame reaches ndo_start_xmit() with the MAC header unset. A driver that reads eth_hdr(skb) on transmit then dereferences skb->head + (u16)~0, an out-of-bounds access ~64 KiB past the head -- the same class fixed for one consumer in commit f5089008f90c ("macsec: do not read an unset MAC header in macsec_encrypt()").\n\npacket_parse_headers() runs only on the transmit path, where skb->data points at the start of the L2 header for every packet-socket type regardless of its length: SOCK_RAW and SOCK_PACKET carry a user-supplied header and SOCK_DGRAM has one built by dev_hard_header(). Reset the MAC header unconditionally, mirroring __dev_queue_xmit(), so the frame is anchored on the bypass path too.\n\nFound by 0sec (https://0sec.ai) using automated source analysis; verified against source and matched to the macsec KASAN report in f5089008f90c. Compile-tested.(CVE-2026-74667)\n\nIn the Linux kernel, the following vulnerability has been resolved: ipvs: clear IPv4 options after rebasing tunnel ICMP errors. ip_vs_in_icmp() rebases an skb from the outer ICMP packet to the quoted original request before passing it to icmp_send(). However, IPCB(skb)->opt still describes the outer IPv4 header. A timestamp option in the outer header can therefore leave an offset that points into the quoted transport header after the rebase. __ip_options_echo() treats a byte at that stale location as the option length and copies it into the fixed-size option storage on the __icmp_send() stack, causing a stack out-of-bounds write.(CVE-2026-74669)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: stop estimator after disabled calc phase\n\nIPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits.\n\nThe kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays, causing a buffer overflow.\n\nExit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize.\n\nEstimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.(CVE-2026-74670)\n\nIn the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values(). In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.(CVE-2026-74673)\n\nIn the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks. The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds, preventing any speculative memory access to client evmasks array.(CVE-2026-74683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nnet: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp()\\n\\nThe commit 4f61f133f354 ("net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur.\\n\\nHowever, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash.\\n\\nFix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().(CVE-2026-74684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nsctp: clear control chunk transport if it is being removed\\n\\nsctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately.\\n\\nIf the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer.\\n\\nOnce an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free.\\n\\nFix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.(CVE-2026-74688)\n\nIn the Linux kernel, the following vulnerability has been resolved: tcp: fix TFO max_qlen accounting across reuseport migration. A listener's TCP_FASTOPEN max_qlen stops being accurate and lets through far more pending Fast Open requests than it was configured for. This only shows up with SO_REUSEPORT listener migration, where closing a listener hands its still-pending TFO children over to a surviving one. fastopenq.qlen is charged in tcp_fastopen_create_child() when the child is created and uncharged in reqsk_fastopen_remove() when the handshake completes. The uncharge follows rsk_listener of the request the child points at, and inet_reqsk_clone() has repointed the child at a new request owned by the new listener, so the ++ and the -- land on two different sockets. The new listener's qlen drifts negative and its limit no longer binds. Charge the new listener during migration, like reqsk_queue_migrated() already does for queue->young and queue->qlen.(CVE-2026-74696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: fix potential use-after-free in tunnel segmentation\n\n__skb_udp_tunnel_segment() gets the UDP header before ensuring the\ntunnel header is in the skb head. If the pull reallocates skb->head,\nthe saved UDP header pointer is no longer valid.\n\nGet the UDP header after the pull to avoid a potential use-after-free.(CVE-2026-74705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Preserve pointer state for commuted arithmetic\n\nWhen scalar += pointer is handled in adjust_ptr_min_max_vals(), the\ndestination register inherits the pointer state from the source pointer.\nCopying only selected fields is fragile because pointer provenance is\ntracked by several bpf_reg_state fields.\n\nUse the caller's temporary offset register to preserve the scalar operand\nwhile replacing the destination with the full pointer state. This preserves\nthe frame number for PTR_TO_STACK registers and keeps parent identity\nfields consistent.(CVE-2026-74720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nbonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor\\n\\nbond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC.\\n\\n  Oops: general protection fault, probably for non-canonical address ...\\n  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\\n  Workqueue: b42 bond_alb_monitor\\n  RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600)\\n   process_one_work (kernel/workqueue.c:3322)\\n   worker_thread (kernel/workqueue.c:3486)\\n   kthread (kernel/kthread.c:436)\\n   ret_from_fork (arch/x86/kernel/process.c:158)\\n  Kernel panic - not syncing: Fatal exception\\n\\nRe-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision.(CVE-2026-74726)\n\nIn the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class(). u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class().(CVE-2026-74739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: inherit needed_headroom and needed_tailroom from phy_dev\n\nipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(),\nbut leave needed_headroom and needed_tailroom set to 0.\n\nWhen the underlying phy_dev (or stacked lower device) requires extra headroom\nor tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or\nveth with rx headroom), upper layers calculating packet headroom and tailroom\nfail to reserve sufficient space.\n\nThis can result in reallocation overhead, skb headroom underflows, or KASAN\nslab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header()\nprepends header data or when lower devices append tailroom.\n\nFix this by:\n1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init().\n2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans\n   in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.(CVE-2026-74744)\n\nIn the Linux kernel, the netfilter/ipset component has a refcount race condition vulnerability. __ip_set_put_byindex() resolved the index to a set pointer under RCU, then took ip_set_ref_lock in __ip_set_put() to decrement set->ref. ip_set_swap() holds that same lock while swapping both the ip_set_list slots and the two sets' ref counters, so it can interleave between the dereference and the lock acquisition, leaving the caller to decrement a set whose reference already moved to the other index and hit BUG_ON(set->ref == 0). list_set_gc() reaches this from timer softirq, which the nfnl mutex does not serialize against swap: an expiring list:set member calls list_set_del() -> ip_set_put_byindex() while IPSET_CMD_SWAP runs on the referenced sets. This vulnerability can cause kernel panic.(CVE-2026-74748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Reject exited events as group leaders\n\nperf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events.\n\nA new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event.\n\nReject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment.\n\n[peterz: make the earlier test fully consistent](CVE-2026-74753)\n\nIn the Linux kernel, a deadlock vulnerability has been found in the ceph filesystem. A reader can hang forever in __ceph_get_caps() when the client no longer holds FILE_RD, but local cap state still says that the capability is already wanted (via mds_wanted). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke FILE_RD from the reader; the next read then has to reacquire FILE_RD. If the cap update that should request FILE_RD never reaches the MDS after cap->mds_wanted was raised, the reader is left holding only non-file caps while local mds_wanted still includes the file read caps, causing the reader to wait indefinitely.(CVE-2026-80527)\n\nIn the Linux kernel, the following vulnerability has been resolved: ceph: avoid fs reclaim while using current->journal_info. handle_reply() stores a ceph_mds_request pointer in current->journal_info while filling the inode and dentry cache from an MDS reply. An allocation in this section can enter direct reclaim and prune dentries from another filesystem. If this dirties an ext4 inode, ext4 starts a JBD2 transaction. JBD2 interprets the Ceph request in current->journal_info as a journal handle and dereferences the request's r_tid as h_transaction, causing a kernel crash.(CVE-2026-80528)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nxfs: don't swallow dquot recovery verification errors\\n\\nxlog_recover_dquot_commit_pass2() validates the recovered dquot with xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2() sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be written back to disk.(CVE-2026-80529)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix OOB read in decode_watchers() via missing bounds check\n\nceph_start_decoding() validates that struct_len bytes remain in the\nbuffer after the encoding header, but accepts struct_len=0 as valid:\nceph_decode_need(p, end, 0, bad) always passes. When a malicious or\ncompromised OSD sends an obj_list_watch_response_t reply with\nstruct_len=0, ceph_start_decoding() returns success with p == end,\nleaving zero bytes guaranteed for subsequent reads.\n\nThe immediately following ceph_decode_32(p) in decode_watchers() has\nno preceding bounds check. With p == end this is a 4-byte read past\nthe validated buffer boundary. The garbage value is then passed\ndirectly to kzalloc_objs() as the watcher count.\n\nThe sibling function decode_watcher() already uses the safe variants\n(ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32)\nafter its own ceph_start_decoding() call. decode_watchers() is the\nonly site that uses the bare variant, confirming an oversight.\n\nFix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end,\n*num_watchers, bad), consistent with the established pattern.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment (e.g. cloud) can trigger this against any kernel client\nthat calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges\nbeyond OSD session establishment.\n\n[ idryomov: trim changelog ](CVE-2026-80557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Avoid using invalid osd indices from primary_temp\n\nA corrupted osdmap received from a Ceph monitor or OSD may contain osd\nindices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts\nthat don't exist, i.e., that are greater than max_osd or smaller than\nCEPH_HOMELESS_OSD (-1). These indices are used to create the up and\nacting set in ceph_pg_to_up_acting_osds(), called from calc_target().\nWhile most of these osd indices are checked, the one from primary_temp\nis not. Subsequently, this may lead to calc_target() returning this\n(potentially invalid) index as target osd for a (linger) request.\nBecause the osd_state, osd_weight, and osd_addr arrays only contain\nmax_osd entries (with indices 0 to max_osd -1), this leads to\nout-of-bounds accesses when trying to read values from these arrays.\n\nThis patch fixes the issue by adding a check to get_temp_osds(), so that\nonly valid osd indices from primary_temp are used, and it falls back to\nusing the primary from pg_temp or the up set if it is invalid.\n\n[ idryomov: changelog ](CVE-2026-80558)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nmptcp: avoid combining some incoming suboptions\\n\\nSome MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes.\\n\\nThe new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux.(CVE-2026-80587)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: stop the timeout timer when releasing a never added disk\n\ndisk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket.\n\nCommit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it.\n\nnvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed, leading to a use-after-free condition.(CVE-2026-80589)\n\nIn the Linux kernel, the following vulnerability has been resolved: tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg. Sashiko found that user can cause this WARN_ON_ONCE() easily with adding a kprobe event based on a raw address with BTF parameter. Since this is not an unexpected condition, remove the WARN_ON_ONCE().(CVE-2026-80607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nRDMA/hns: Fix warning in poll cq direct mode\\n\\nCQs allocated by ib_alloc_cq() always have a comp_handler. Though\\nin direct mode this handler is never expected to be called, it\\nis still called when the driver is reset, triggering the following\\nWARN_ONCE():\\n\\nCall trace:\\nib_cq_completion_direct+0x38/0x60\\nhns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2]\\nhns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2]\\nhns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2]\\nhns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2]\\nhclge_notify_roce_client+0x60/0xbc [hclge]\\nhclge_reset_rebuild+0x48/0x34c [hclge]\\nhclge_reset_subtask+0xcc/0xec [hclge]\\nhclge_reset_service_task+0x80/0x160 [hclge]\\nhclge_service_task+0x50/0x80 (hclge]\\nprocess_one_work+0x1cc/0x4d0\\nworker_thread+0x154/0x414\\nkthread+0x104/0x144\\nret_from_fork+0x10/0x18(CVE-2026-80647)","modified":"2026-09-13T16:45:50.310445310Z","published":"2026-09-14T16:33:36Z","upstream":["CVE-2026-31668","CVE-2026-46325","CVE-2026-64082","CVE-2026-64523","CVE-2026-68082","CVE-2026-68136","CVE-2026-68159","CVE-2026-68205","CVE-2026-68426","CVE-2026-68471","CVE-2026-72111","CVE-2026-72213","CVE-2026-72288","CVE-2026-72294","CVE-2026-72321","CVE-2026-72329","CVE-2026-72398","CVE-2026-72404","CVE-2026-72405","CVE-2026-72423","CVE-2026-74302","CVE-2026-74317","CVE-2026-74386","CVE-2026-74439","CVE-2026-74473","CVE-2026-74475","CVE-2026-74476","CVE-2026-74481","CVE-2026-74485","CVE-2026-74487","CVE-2026-74499","CVE-2026-74514","CVE-2026-74536","CVE-2026-74586","CVE-2026-74587","CVE-2026-74588","CVE-2026-74589","CVE-2026-74591","CVE-2026-74606","CVE-2026-74608","CVE-2026-74609","CVE-2026-74610","CVE-2026-74611","CVE-2026-74612","CVE-2026-74614","CVE-2026-74615","CVE-2026-74616","CVE-2026-74620","CVE-2026-74623","CVE-2026-74624","CVE-2026-74636","CVE-2026-74637","CVE-2026-74656","CVE-2026-74660","CVE-2026-74662","CVE-2026-74666","CVE-2026-74667","CVE-2026-74669","CVE-2026-74670","CVE-2026-74673","CVE-2026-74683","CVE-2026-74684","CVE-2026-74688","CVE-2026-74696","CVE-2026-74705","CVE-2026-74720","CVE-2026-74726","CVE-2026-74739","CVE-2026-74744","CVE-2026-74748","CVE-2026-74753","CVE-2026-80527","CVE-2026-80528","CVE-2026-80529","CVE-2026-80557","CVE-2026-80558","CVE-2026-80587","CVE-2026-80589","CVE-2026-80607","CVE-2026-80647"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3708"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46325"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64082"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64523"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68082"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68159"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68205"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68426"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68471"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72213"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72288"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72294"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72321"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72329"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72398"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72404"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72405"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72423"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74386"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74439"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74473"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74475"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74481"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74485"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74487"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74499"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74514"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74536"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74586"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74587"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74589"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74591"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74606"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74608"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74609"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74610"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74612"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74614"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74615"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74616"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74620"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74623"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74624"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74636"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74656"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74660"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74666"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74667"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74670"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74683"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74684"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74688"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74696"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74720"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80528"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80529"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80557"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80558"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80587"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80589"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80607"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80647"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP3","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","bpftool-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-debugsource-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-devel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-extra-modules-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-headers-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-source-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-tools-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","kernel-tools-devel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","perf-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","perf-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","python3-perf-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.aarch64.rpm"],"src":["kernel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.src.rpm"],"x86_64":["bpftool-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","bpftool-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-debugsource-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-devel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-extra-modules-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-headers-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-source-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-tools-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","kernel-tools-devel-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","perf-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","perf-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","python3-perf-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.3.30.161.20260910.f620d9c7c985.oe2403sp3.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3708.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L"}]}