{"id":"OESA-2026-4185","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\nnetfilter: ipset: fix race between dump and ip_set_list resize\n\nThe release path of ip_set_dump_do() and ip_set_dump_done() read\ninst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()\nof the array pointer. These run from netlink_recvmsg() without the nfnl\nmutex and without an RCU read-side critical section.\n\nA concurrent ip_set_create() can grow the array: it publishes the new\narray, calls synchronize_net() and then kvfree()s the old one. Since the\ndump paths read the array outside any RCU reader, synchronize_net() does\nnot wait for them and the old array can be freed while they still index\ninto it, causing a use-after-free.\n\nThe dumped set itself stays pinned via set->ref_netlink, so only the\narray load needs protecting. Take rcu_read_lock() around it, matching\nip_set_get_byname() and __ip_set_put_byindex().\n\n  BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)\n  Read of size 8 at addr ffff88800b5c4018 by task exploit/150\n  Call Trace:\n   ...\n   kasan_report (mm/kasan/report.c:595)\n   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)\n   netlink_dump (net/netlink/af_netlink.c:2325)\n   netlink_recvmsg (net/netlink/af_netlink.c:1976)\n   sock_recvmsg (net/socket.c:1159)\n   __sys_recvfrom (net/socket.c:2315)\n   ...\n  Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI\n  KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]\n  RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)\n  Kernel panic - not syncing: Fatal exception(CVE-2026-64189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: drop a chunk if its transport was removed\n\nsctp_rcv() resolves the transport once per packet and leaves it in\nchunk->transport. The lookup reference, or the one sctp_add_backlog() takes\nif the socket is owned by userspace, keeps it around until the chunk has\nbeen processed.\n\nAn authenticated ASCONF DEL-IP can remove it in the meantime.\nsctp_assoc_rm_peer() takes the transport out of the association and calls\nsctp_transport_free(), which tags it dead and drops the reference the\nassociation held. There is a window on both paths: the packet can sit on\nthe socket backlog, and on the direct path the lookup completes before\nbh_lock_sock().\n\nThe DATA chunk in that packet puts the removed transport back into\nasoc->peer.last_data_from. Once the packet is done that reference goes\naway and the transport is freed by RCU, so the next delayed SACK carries\nthe pointer into the SACK chunk and sctp_outq_select_transport() reads the\nfreed transport's state.\n\nDrop the chunk in sctp_inq_push(), next to the existing rcvr->dead check.\nBoth paths reach it with the association's socket lock held. The peer\nretransmits it.(CVE-2026-89478)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: stop processing a packet once its association is deleted\n\nsctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is\nNULL, and caches the result in chunk->asoc and chunk->transport without\ntaking a reference.\n\nA packet that matches no association is handed to the endpoint, so a peer\ncan bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The\nCOOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and\nwith the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(),\nso the association and its transports are freed.\n\nThe endpoint loop has no counterpart to the asoc->base.dead check in\nsctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed\ntransport and is then passed to sctp_do_sm() with the freed association.\nThe transport is freed through RCU, so this needs the packet to come off\nthe socket backlog, where the loop runs in task context.\n\nThe endpoint loop cannot do the same check: it holds no reference on the\nassociation, so reading asoc->base.dead would itself be a use-after-free.\nMark the packet for discard in the command interpreter, just before it\ndeletes the association. That is also before sctp_inq_free() releases the\nchunk on the association receive path.\n\nsctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary\nassociation, while the one the packet belongs to stays alive. A restarting\npeer can bundle DATA behind its COOKIE ECHO, so compare against\nchunk->asoc and leave that case alone.(CVE-2026-89479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Lock the handler in ucma_set_ib_path()\n\nucma_set_ib_path() calls ucma_event_handler() straight from the write()\npath, without the handler lock that keeps ctx->file stable while a uevent\nis queued.  The handler re-reads ctx->file for every dereference:\n\n\tmutex_lock(&ctx->file->mut);\t\t\t/* file A */\n\tlist_add_tail(&uevent->list, &ctx->file->event_list);\t/* file B */\n\tmutex_unlock(&ctx->file->mut);\t\t\t/* file B */\n\twake_up_interruptible(&ctx->file->poll_wait);\t/* file B */\n\nA concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION\ncaller sleeps in mutex_lock(), so the list_add_tail() lands on file B's\nevent_list while only file A's mutex is held, racing every other user of\nthat list:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0\n  Read of size 8 at addr ffff888153c6a418 by task poc_corr/486\n  Call Trace:\n   __list_add_valid_or_report+0x1aa/0x1c0\n   ucma_event_handler+0x1be/0xc00\n   ucma_set_ib_path+0x45e/0x710\n   ucma_set_option+0x32e/0x590\n   ucma_write+0x1f9/0x330\n  Allocated by task 505:\n   ucma_write_cm_event+0x1a1/0x660\n  Freed by task 505:\n   kfree+0x1da/0x4c0\n   ucma_get_event+0x5d5/0x7e0\n\nThe freed object is a ucma_event that another thread dequeued from file B's\nlist under file B's mutex.  File A's mut is left held on top of that,\nwedging its next writer in uninterruptible sleep.\n\nThis path needs a bound and address-resolved cm_id, so it requires an RDMA\ndevice to be present.\n\nTake the handler lock around the call.(CVE-2026-89508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cxgb4: Cancel reg_work before freeing device on remove\n\nc4iw_uld_state_change() queues reg_work to register the RDMA device.\nc4iw_remove() can free ctx->dev while this work is pending or running,\nleaving c4iw_register_device() accessing the freed device.\n\nCancel reg_work before removing the device.  The registration work can\ntear down ctx->dev when registration fails, so do not unregister or\ndeallocate it again in that case.\n\nThis issue was found by an in-house static analysis tool.(CVE-2026-89510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Make core-sched flips wait for in-flight selections\n\nCore scheduling's pick_next_task() operates on all sibling rqs under one\nacquisition of the shared core-wide lock. A ->pick_task() that releases the\nrq lock leaves every sibling __lock momentarily free, letting\n__sched_core_flip(false) complete mid-selection and rebind rq_lockp() under\nit. The selection resumes on the split locks, touching sibling state it no\nlonger protects, and __schedule() finally releases a lock that was never\ntaken while leaking the one that was.\n\nCount in-flight core-wide selections in the leader's rq->core_pick_in_flight\nand make __sched_core_flip() wait for the count to drain. The count only\nchanges under the shared lock, which the flip holds while sampling, so no\nother ordering is needed. The wait can repeat while selections overlap, but\nthe flip backs off between samples and flips are rare cookie-lifetime\nevents.\n\nsched_core_cpu_deactivate() moves the count to the new leader - a stale copy\nleft behind would bias it forever if that CPU later returns as its own\nleader.(CVE-2026-89520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmpls: reload header after pskb_may_pull()\n\nmpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop\nwhen an MPLS route has multiple nexthops.  While walking the MPLS label\nstack, the hash routine caches hdr for the current label.  After finding\nthe bottom-of-stack label, it calls pskb_may_pull() before reading the\ninner IP header.\n\nIf an skb is constructed with the inner IP header in nonlinear data and\ninsufficient tailroom in the linear head, pskb_may_pull() calls\npskb_expand_head() to replace the skb head and free the old one.  This\nleaves hdr pointing to freed memory.  The IPv6 path can invalidate hdr\nagain when it performs a second pull for the larger header.\n\nThe issue was found through static analysis.  A reproducer sending a legal\nGeneve packet through a bareudp/MPLS multipath setup triggered the same\nKASAN report in 2 of 2 unpatched runs:\n\n  BUG: KASAN: slab-use-after-free in mpls_select_multipath\n  Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23\n\n  Call Trace:\n   mpls_select_multipath\n   mpls_forward\n   __netif_receive_skb_list_core\n   netif_receive_skb_list_internal\n   napi_complete_done\n   gro_cell_poll\n   __napi_poll\n   net_rx_action\n\n  Freed by task 23:\n   kfree\n   pskb_expand_head\n   __pskb_pull_tail\n   mpls_select_multipath\n\nReload hdr from the current skb head after each successful pull before\nderiving the inner IPv4 or IPv6 header pointer.(CVE-2026-89555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Prevent integer overflow in __nd_label_validate()\n\nThe on-media namespace index field nslot is a u32 read from the DIMM\nlabel storage area.  __nd_label_validate() bounds it against the config\narea size, but sizeof_namespace_label() returns unsigned, so the product\nnslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before\nthe comparison.  A crafted nslot passes the bound and is then used as the\nloop trip count in nd_label_data_init(), whose memset() walks off the end\nof the config_size buffer: an out-of-bounds write.\n\nThe field is not trusted -- it comes from the medium, or from userspace\nvia ND_CMD_SET_CONFIG_DATA.  Evaluate the product in 64-bit so the bound\ncheck is exact; conforming labels are unaffected.\n\nThe check was safe when introduced by commit 4a826c83db4e ("libnvdimm:\nnamespace indices: read and validate"): it multiplied by sizeof(struct\nnd_namespace_label), a size_t, so on a 64-bit build the product did not\nwrap.  Commit 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label\ndefinitions") narrowed it to 32 bits when the label size became a runtime\nvalue read via sizeof_namespace_label().(CVE-2026-89559)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable preemption in __bpf_get_stack\n\nget_perf_callchain() returns a per-CPU perf_callchain_entry buffer and\nreleases its recursion slot via put_callchain_entry() before returning,\nso nothing keeps the entry reserved while __bpf_get_stack() consumes\nit below.\n\nA preemptible BPF program (e.g. a non-sleepable raw tracepoint program\non a PREEMPT kernel, which runs under migrate_disable() but not\npreempt_disable()) can be scheduled out between obtaining the entry\nand the copy. Another task scheduled on the same CPU then reuses the\nsame per-CPU buffer and overwrites trace->nr with a larger value.\ncopy_len is then computed from the inflated trace->nr and can exceed\nthe caller's buffer, causing an out-of-bounds write in the memcpy()\nand in the build_id path.\n\nThe rcu_read_lock() taken here alone does not prevent this. It is\nonly taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does\nnot disable preemption; it merely keeps perf's callchain buffer array\nalive (freed via call_rcu()) and does nothing to stop another task\nfrom reusing the entry.\n\nDisable preemption around obtaining the callchain entry and copying\nit into the caller's buffer, so the entry cannot be reused underneath\nus and trace->nr stays bounded by max_depth. Build ID resolution may\nfault and is therefore deferred until after preemption is re-enabled;\nby then the instruction pointers have already been copied into buf,\nso it operates only on that private copy. Note, preempt_disable() also\nsubsumes the buffer-lifetime guarantee the rcu_read_lock() provided,\nsince a preempt-disabled section is an RCU read-side critical section\nfor the callchain buffers' call_rcu() reclaim.\n\n\n[ changed Fixes: commit ](CVE-2026-89580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: clear ce->tgthint in free_tgts()\n\nWhen free_tgts() frees all structures in ce->tlist, ce->tgthint\nis left pointing to one of the freed cache_dfs_tgt structures.\n\nIf ce->tgthint is not reset before it is used later, it results\nin a use-after-free.\n\nSet ce->tgthint to NULL in free_tgts() after the elements are\nfreed to reflect that no elements remain.(CVE-2026-89636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: do not repeat ceph_trim_dentries() if no progress possible\n\nceph_cap_reclaim_work() re-queues itself for as long as\nceph_trim_dentries() returns -EAGAIN, which happens whenever a lease\nwalk exhausts its `nr_to_scan` budget.  This creates a busy loop that\nconsumes CPU without making any progress when there is nothing to\nreclaim: with no cap pressure (`count==0`) and every scanned lease\nstill valid, each pass runs the full scan budget down to zero and\nreturns `-EAGAIN`, only to be queued again immediately.\n\nThe dir-lease walk made this worse.  When `expire_dir_lease` is\n`false` (i.e. we have no intention of reclaiming dir leases),\n__dir_lease_check() returned `TOUCH` for every valid lease.  `TOUCH`\nmoves the dentry to the tail of the list and resets `di->time` via\n__dentry_dir_lease_touch(), so a walk over N valid leases pointlessly\nrewrote the list, refreshed the timestamps (preventing them from ever\naging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN`\nrequeue.\n\nFix this in three steps:\n\n - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is\n   `false`.  If we are not going to reclaim the lease, leave it in\n   place instead of churning the list and resetting its timestamp; the\n   walk then terminates naturally (or via `STOP` at the first fresh\n   lease).\n\n - Only return `-EAGAIN` from the first (dentry-lease) walk when something\n   was actually freed.  A full batch that frees nothing means retrying\n   the same list immediately is futile; fall through to the dir-lease\n   walk instead.\n\n - After both walks, bail out with success (0) when nothing was freed\n   and there is no cap pressure (`count==0`).  There is no reason to\n   keep retrying when we are not over the cap limit and made no\n   progress.\n\nUnder real cap pressure (`count>0`) the reclaim path is unchanged and\nstill retries via `-EAGAIN`.\n\nWithout this patch, I saw 500 ceph_trim_dentries() calls per second on\nour web servers.  This is very visible in `/proc/lock_stat` (5 minute\ncapture):\n\n              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg\n\n &mdsc->dentry_list_lock:        126180         128218           0.04        8063.44    15986965.20         124.69        1573354        5296812           0.04        8291.28    74164526.48          14.00\n -----------------------\n &mdsc->dentry_list_lock         111736          [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n &mdsc->dentry_list_lock           2631          [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8\n &mdsc->dentry_list_lock           3878          [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8\n &mdsc->dentry_list_lock           9973          [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0\n -----------------------\n &mdsc->dentry_list_lock         123621          [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8\n &mdsc->dentry_list_lock           1822          [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n &mdsc->dentry_list_lock           2720          [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0\n &mdsc->dentry_list_lock             55          [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8\n\nWith this patch:\n\n              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg\n\n &mdsc->dentry_list_lock:          1203           1215           0.16         408.88       33082.88          27.23        4320501        7357389           0.04         500.64     1961578.00           0.27\n -----------------------\n &mdsc->dentry_list_lock           1029          [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n &mdsc->dentry_list_lock            1\n---truncated---(CVE-2026-89647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: cap delegated inode count in ceph_parse_deleg_inos()\n\nceph_parse_deleg_inos() decodes interval sets of delegated inode numbers\nfrom an MDS create-with-delegation reply. For each set it reads a 64-bit\nstart and a 64-bit len with ceph_decode_64_safe(), which only validates\nthat the eight bytes are present in the message, not the value, and then\nloops over len while inserting entries into s_delegated_inos.\n\nlen is fully attacker controlled. A malicious or compromised MDS can send\none huge interval, many intervals in one reply, duplicate intervals, or\nrepeated replies that accumulate delegated inodes on the same session.\nThe original code bounded none of these and could spin the insert loop or\ngrow the xarray without limit.\n\nBound both dimensions with a single enforcement point. Track the number\nof delegated inodes held by each MDS session in an atomic counter and\ngrow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless()\nto refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper\nis the only place the counter grows, the per-session population can never\nexceed the cap, so no separate per-session pre-check is needed. The\ncounter is decremented when async create consumes a delegated inode or\nwhen an insert fails, incremented when a delegated inode is restored,\ninitialized with the session xarray, and reset when reconnect destroys\nthe xarray.\n\nA per-session cap alone still lets one reply spin the insert loop on\nduplicate ranges without growing the counter, so also cap the aggregate\ninterval length accepted from a single reply. Together these bound both\nthe loop trip count per reply and the xarray population across replies.\n\nThe cap is a fixed, client-chosen constant rather than a value derived\nfrom the MDS. mds_client_prealloc_inos is a userspace MDS configuration\noption; it is never sent to the kernel client on the wire, and a\nserver-supplied bound could not be trusted for a defensive limit in any\ncase. The constant is set well above that option's documented default of\n1000 (a generous multiple), so legitimate refill behavior is unaffected\nwhile the CPU and xarray memory a malformed delegation stream can consume\nstays bounded.\n\nImpact: a malicious or compromised Ceph MDS can no longer make a client\nspin through an unbounded delegated-inode interval or grow one session's\ndelegated-inode xarray without limit.(CVE-2026-89648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reject buckets with mismatched CRUSH ids\n\ncrush_decode() stores bucket data by array slot, and the mapper later\nderives the per-bucket workspace index from the decoded bucket id. A\nmalformed map can therefore make one bucket reuse another bucket's\nworkspace by encoding an id different from -1 - slot.\n\nFor uniform buckets, the second replica selection expands the source\nbucket's permutation into that aliased workspace buffer. If the source\nbucket is larger than the aliased bucket, the write runs past the smaller\npermutation array and can escape the kvmalloc'd CRUSH workspace. KASAN\nreports a slab OOB write of 4 bytes in bucket_perm_choose().\n\nReject buckets whose encoded id does not match their array slot. Valid\nCRUSH maps already use the canonical negative id corresponding to the\nbucket slot, so this restores the invariant expected by\nwork->work[-1 - in->id] without changing valid map behavior.(CVE-2026-89656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix out-of-bounds write when null terminating a label vec\n\naa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE\nis passed. If the components are all distinct no duplicates are dropped,\ndups is 0 and the terminator goes to vec[n], so the caller has to provide\nroom for n + 1 entries.\n\naa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len,\ngfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but\nvec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES\nit uses the local array of LOCAL_VEC_ENTRIES pointers, above that it\nallocates exactly len pointers. The terminator therefore lands one entry\npast the end of the local array when len is LOCAL_VEC_ENTRIES, and one\nentry past the end of the allocation when len is larger.\n\nlen comes from the number of "//&" separated components in the label name\nand label_count_strn_entries() does not bound it. An unprivileged task\nreaches the parse by writing to /proc/self/attr/apparmor/current or through\nlsm_set_self_attr(2), both of which go through do_setattr(), and the name\nis parsed before the change_profile permission is checked.\nThe query_label() path behind the securityfs .access file, which is\nmode 0666, performs no permission check at all. Every component has to\nresolve to a loaded profile, so a system with policy loaded is required.\n\nThe other two VEC_FLAG_TERMINATE users work on a label vec that\naa_label_alloc() has already sized with "+ 1 for null terminator entry on\nvec". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing\nlen + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of\nthe local array and into kzalloc().(CVE-2026-89761)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix cred UAF caused by begin_current_label_crit_section()\n\nAppArmor's begin_current_label_crit_section() is a scary function called\nfrom lots of LSM hooks (in particular VFS/socket-related ones) that checks\nif the label referenced by the current creds is marked FLAG_STALE, and if\nso, attempts to use aa_replace_current_label() to replace the creds with an\nupdated version that uses a new label.\n\nThe first problem with this is that it would directly lead to UAF of\n`struct cred` if anything in the kernel takes a pointer to the current\ncreds and accesses these past a security hook invocation that replaces\ncreds, like so:\n```\nconst struct cred *cred = current_cred();\nalloc_file_pseudo(...);\nuid_t uid = cred->euid;\n```\nI don't know if anything in the kernel actually does this, but I think it\nis very surprising that this pattern could lead to UAF.\n\nThe second problem is that things go wrong when aa_replace_current_label()\nruns with overridden credentials. aa_replace_current_label() bails out if\n`current_cred() != current_real_cred()` (mirroring the check in\nproc_pid_attr_write()), but this check can't actually reliably detect\noverridden credentials because the overridden creds can be the same as the\nobjective creds.\n\nSo in approximately the following scenario, things go wrong:\n\n1. task begins with <creds A> (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on <creds A> for overriding\n3. task calls override_creds(<creds A>), which returns a pointer to the old\n   subjective creds (<creds A>)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on\n   <creds A>\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(<creds A>)\n9. now task->cred is <creds A> while task->real_cred is <creds B>, but the\n   task_struct logically holds two references to <creds B>\n10. another task drops the extra reference on <creds A> that was used for\n    overriding, refcount drops to 0\n11. now task->real_cred points to freed creds\n\nAt this point, any access to current_cred() will be UAF.\n\nI have a test case where I run aa-disable on a profile while a process\nusing that profile is blocked on splice() from a FUSE passthrough file into\na full pipe; after the profile update, the pipe becomes empty, splice()\nresumes, the credentials go out of sync, and a subsequent getuid() syscall\nresults in a KASAN UAF splat.\n\nTo fix this, instead of directly replacing creds, do it via task_work that\nwill run at the end of the current syscall. (The point in time at which the\ncred replacement happens should have no correctness impact; it is just a\nperformance optimization to avoid unnecessarily touching the refcount of\nthe new label.)\n\nNote that AppArmor still performs direct cred replacements in the\nsb_pivotroot LSM hook after this change, and that direct cred replacements\ncan still happen in VFS ->write() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new->label_replacement_pending after the entire\naa_task_ctx has been copied, or switch to manually copying members over.\nI am switching to manually copying members over because that should make\nbugs more obvious.(CVE-2026-89762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix TPM teardown ordering\n\ntrusted_tpm_exit() drops the TPM chip reference and frees the digest\narray before unregistering the trusted key type. key_type_lookup()\nholds key_types_sem for reading until the key operation finishes, while\nunregister_key_type() takes it for writing. It therefore provides the\nsynchronization point that must precede backend teardown.\n\nThe current order permits this interleaving:\n\n  CPU 0                              CPU 1\n  trusted_tpm_exit()                 key_type_lookup("trusted")\n    put_device(&chip->dev)             trusted_tpm_seal()\n    kfree(digests)                       pcrlock()\n    unregister_key_type()                  tpm_pcr_extend(..., digests)\n\nCPU 1 can consequently dereference the freed digest array. The chip can\nalso be released before callbacks stop using it.\n\nKASAN reported:\n\n  BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200\n  Read of size 2 at addr ffff88810872d000 by task poc/89\n  Call Trace:\n    tpm_pcr_extend+0x1f0/0x200\n    pcrlock+0x42/0x70 [trusted]\n    trusted_tpm_seal+0x1b6/0x570 [trusted]\n    trusted_instantiate+0x293/0x340 [trusted]\n    __key_instantiate_and_link+0xb2/0x2b0\n    __key_create_or_update+0x61e/0xb50\n    __do_sys_add_key+0x1b8/0x310\n  Allocated by task 88:\n    __kmalloc_noprof+0x1a7/0x490\n    do_one_initcall+0xa1/0x390\n    do_init_module+0x2df/0x840\n  Freed by task 90:\n    kfree+0x131/0x3c0\n    trusted_tpm_exit+0x59/0xa0 [trusted]\n    __do_sys_delete_module+0x346/0x510\n\nMove unregister_key_type() before releasing either resource. This stops\nnew lookups and waits for in-flight key operations to finish before the\nbackend state is destroyed.(CVE-2026-89763)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: hold sk properly in sco_conn_ready\n\nsk deref in sco_conn_ready must be done either under conn->lock, or\nholding a refcount, to avoid concurrent close. conn->sk and parent sk is\ncurrently accessed without either, and without checking parent->sk_state:\n\n    [Task 1]            [Task 2]\n                        sco_sock_release\n    sco_conn_ready\n      sk = conn->sk\n                          lock_sock(sk)\n                            conn->sk = NULL\n      lock_sock(sk)\n                          release_sock(sk)\n                          sco_sock_kill(sk)\n       UAF on sk deref\n\nand similarly for access to sco_get_sock_listen() return value.\n\nFix possible UAF by holding sk refcount in sco_conn_ready() and making\nsco_get_sock_listen() increase refcount. Also recheck after lock_sock\nthat the socket is still valid.  Adjust conn->sk locking so it's\nprotected also by lock_sock() of the associated socket if any.(CVE-2026-89774)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable preemption in bpf_get_stackid\n\nThe get_perf_callchain call needs disabled preemption plus we need\nit disabled as long as we access its returned trace entries buffer.\n\nNote the bpf_get_stackid_pe function is executed already with\npreemption disabled.(CVE-2026-89799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: saa7164: fix cleanup on resource allocation failure\n\nsaa7164_dev_setup() adds the device to the global saa7164_devlist before\nrequesting the PCI BAR memory regions.\n\nIf get_resources() fails, saa7164_dev_setup() decrements the device count\nand returns an error, but leaves the device on saa7164_devlist. The probe\nerror path then frees the device, leaving a dangling entry on the global\nlist.\n\nReuse the existing MMIO mapping error path to remove the device from\nsaa7164_devlist and decrement the device count before returning.\n\nAlso release BAR0 if it was successfully requested but the BAR2 request\nfails.(CVE-2026-89877)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: reject geometry changes while the VBI queue is busy\n\nvidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide\ndev->width / dev->norm but only refuse the change when the *video* queue\n(dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry:\ncx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm,\nthe VBI videobuf2 plane is sized from dev->width / dev->norm in\nvbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then\nrecomputes the destination offset from the *live* dev->width and the\nlatched lines_per_field on every URB completion:\n\n\toffset = lines_completed * (dev->width << 1) + ...;\n\tif (dma_q->current_field == 2)\n\t\toffset += dev->width * 2 * dma_q->lines_per_field;\n\tmemcpy(plane + offset, p_buffer, lencopy);\n\nBecause the VBI node shares video_ioctl_ops with the video node, an\napplication can size a small VBI plane (REQBUFS/QBUF with a small width,\nor with the NTSC standard), then enlarge dev->width (or switch dev->norm\nto PAL) through the video node while the VBI stream is running -- the\nchange is allowed because only dev->vidq is checked -- and let the device\ndeliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the\noffset with the larger geometry and memcpy()s past the end of the smaller\nplane that was already allocated, a heap out-of-bounds write whose offset\nis attacker-chosen and whose contents come from the device. The\nper-field guard in cx231xx_copy_vbi_line() does not help: it bounds the\ncopy against the latched lines_per_field, not the plane's real capacity,\nand vb2 does not re-run buf_prepare() for an already prepared buffer.\n\nRefuse the format/standard change when the VBI queue is busy as well, so\nthe geometry cannot change underneath an allocated VBI buffer.(CVE-2026-89894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cec: Serialize exclusive follower delivery\n\ncec_receive_notify() reads the exclusive follower pointer without the\nadapter lock. Serialize the no-follower check and message delivery\nagainst mode changes and release.(CVE-2026-89897)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cec: disable delayed work before freeing an interrupted transmit\n\ncec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in\nwait_for_completion_killable(). If that wait is interrupted by a signal,\ncancel_delayed_work_sync() can run before the CEC kthread arms the reply\ntimeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts().\nThe work is then armed after the cancel, and the data is freed with its\ndelayed_work still pending:\n\n  ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout\n\nUse disable_delayed_work_sync(): it cancels the work and disables it, so\nthe later schedule_delayed_work() becomes a no-op and the work cannot be\nre-armed. The data is freed right after, so it need not be re-enabled.(CVE-2026-89899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: reject unsolicited H2CData PDUs\n\nnvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking\nthat its TTAG is a valid in-range command index and that the command's\ndata buffers are mapped. It never checks that the target has actually\nsolicited that data by sending an R2T for the command.\n\nA remote host can abuse this. It submits a write command that takes the\nR2T path and, before the target transmits the R2T, sends an H2CData PDU\nfor that command's tag. The data completes the command early, and when\nthe command then fails synchronously (e.g. a length mismatch caught by\nnvmet_check_transfer_len()), it is completed a second time. Each\ncompletion calls nvmet_tcp_queue_response(), so the same command is added\nto queue->resp_list twice while it is still linked; the second llist_add()\nmakes the node point to itself (lentry->next == lentry).\n\nnvmet_tcp_process_resp_list() then walks that self-referential node and\nadds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this\ntrips the "list_add double add" check (kernel BUG); without it the loop\nnever terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is\nremotely triggerable and needs no authentication on an allow_any_host\nsubsystem.\n\nTrack whether an R2T has been transmitted for a command and reject an\nH2CData PDU that arrives before it. The flag is cleared on command reuse\n(nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple\nH2CData PDUs of a single solicited transfer.(CVE-2026-89968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix out-of-bounds write when receiving an over-long PDU\n\nnvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte\nqueue->pdu union, then computes the remaining payload length as\n\n\tqueue->left = hdr->hlen - queue->offset + hdgst;\n\nand reads that many more bytes into &queue->pdu + queue->offset, without\never bounding the result against sizeof(queue->pdu).\n\nA struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the\nunion. Once a header digest has been negotiated (hdgst = 4), a second\nICReq passes the hlen == nvmet_tcp_pdu_size() check but yields\nqueue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the\n128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and\nqueue->data_digest. Those bytes are attacker-controlled (an ICReq\ncarries no digest), and the duplicate ICReq is only rejected later,\nafter the overflow. A remote unauthenticated host can thus corrupt\nkernel memory adjacent to the receive buffer.\n\nReject any PDU whose declared length would read past the end of\nqueue->pdu before the second recv.(CVE-2026-89969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: add missing SRCU grace period in error path\n\nnvme_alloc_ns() error path at out_unlink_ns removes ns from the\nnamespace head siblings list with list_del_rcu(&ns->siblings) but\ndoes not wait for SRCU readers before freeing the namespace struct.\nMultipath code iterates the head->list under srcu_read_lock() in\nnvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent\nreader can still hold a reference to ns when kfree(ns) runs.\n\nThe normal removal path in nvme_ns_remove() correctly calls\nsynchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for\nin-progress readers. Add the same grace period in the error path.(CVE-2026-89972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Protect kprobe_blacklist with RCU\n\n__within_kprobe_blacklist() traverses kprobe_blacklist without holding\nkprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist()\nremoves blacklist entries and immediately frees them with kfree().\nA concurrent call to within_kprobe_blacklist() can therefore dereference\nfreed memory.\n\nFurthermore, within_kprobe_blacklist() can be called in atomic or\nnon-preemptible contexts where the sleeping kprobe_mutex cannot be taken.\n\nProtect kprobe_blacklist with RCU. Use guard(rcu)() and\nlist_for_each_entry_rcu() for traversal, list_add_tail_rcu() for\ninsertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim\nentries safely after a grace period.(CVE-2026-89988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Take trace_array reference before accessing its ftrace_ops\n\nThe trace instance files set_ftrace_filter and set_ftrace_notrace was\nupdated to work with specific trace instances (trace_arrays). The issue is\nthat when these files are opened, there is a small race window where it\nwill use the ftrace_ops from the inode->private pointer to get a reference\nto the trace_array and then take its reference. The problem is that the\nftrace_ops itself could be freed. If the rmdir on the instance happens at\nthe same time the set_ftrace_filter file is opened, the rmdir could have\nalso freed the ftrace_ops and referencing it will cause a use-after-free\nbug and crash the kernel.\n\nInstead, pass in the trace_array as the file private data (NULL for the\ntop level instance), and then pass both the trace_array and the ftrace_ops\nto the ftrace_regex_open() function. If the trace_array is NULL, then it\njust uses the ftrace_ops without the need to take its reference (like\nnormal). If the ftrace_ops is NULL, that is only the case for the top\nlevel instance and the global_ops can be used.\n\nThis allows the trace_array to have its reference incremented before\ntouching the ftrace_ops that could also be freed when the instance is.(CVE-2026-90002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Reserve a terminator byte for the login payload\n\niscsi_target_check_login_request() rejects a login PDU whose\nDataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and\nlogin->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS\nbytes. Since iscsit_get_login_rx() receives payload_length + padding\nbytes, where\n\n\tpadding = ((-payload_length) & 3);\n\nany payload_length from 8189 to 8192 fills the whole 8192 byte\nbuffer. The write stays in bounds, but no byte is left for a NUL\nterminator.\n\nThe buffer is subsequently consumed as a C string. In the CHAP path\nchap_check_algorithm() calls kstrdup(a_str), and extract_param() calls\nstrstr(in_buf, pattern) followed by strlen_semi(), none of which take a\nlength. convert_null_to_semi() additionally rewrites every embedded NUL\nto ';', so even a payload made of well formed NUL separated key=value\nrecords is left without a terminator. These walk past the end of the\nobject into adjacent slab memory. It is reachable by an unauthenticated\ninitiator against a portal configured for CHAP; when authentication is\nnot required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and\nthe CHAP path is never entered.\n\nAllocate one extra byte. kzalloc() zeroes it and nothing ever writes to\nit, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS\nbytes, so the buffer is always terminated.(CVE-2026-90011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent client use-after-free during blocked-lock reaping\n\nA bare lock owner -- its only remaining reference a blocked lock on\nnn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but\nno reference keeping the client alive. When the per-net laundromat\nreaps such a lock, freeing the nbl drops the owner reference\nheld through flc_owner, and the final nfs4_put_stateowner()\ntakes the client's cl_lock. Because the laundromat detaches the\nnbl first, __destroy_client() no longer finds it, so a concurrent\nforce_expire_client() can free the client before nfs4_put_stateowner()\nruns, dereferencing cl_lock in freed memory.\n\nPin the client with cl_rpc_users before dropping\nnn->blocked_locks_lock, and skip clients already expiring, whose\nblocked locks __destroy_client() frees while holding an owner\nreference. Take nn->client_lock outside nn->blocked_locks_lock.\nEvery other site holds nn->blocked_locks_lock as a leaf, acquiring\nno further lock, so placing nn->client_lock outside it cannot form\na lock-order cycle.(CVE-2026-90036)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent client use-after-free during close_lru reaping\n\nAn nfs4_openowner left on nn->close_lru after its final CLOSE keeps\nits last closed stateid in oo_last_closed_stid, holding only a raw\npointer to its nfs4_client. The laundromat reaps timed-out entries,\ndrops nn->client_lock, and calls nfs4_put_stid(), which dereferences\nthe client through cl_lock. Nothing pins the client across that\nwindow, so a concurrent force_expire_client() can free it and\nnfs4_put_stid() reads freed memory. __destroy_client() hits the same\nrace, walking clp->cl_openowners without cl_lock.\n\nPin the client with cl_rpc_users before dropping client_lock, and\nskip clients already expiring. __destroy_client() then cleans up its\nown close_lru entries through release_last_closed_stateid(), so\nteardown no longer races the laundromat.(CVE-2026-90037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan\n\nFor L2CAP sockets without owning sk->sk_socket, reading\nl2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() ->\nl2cap_sock_put_chan().  This excludes simultaneous proto_ops callbacks,\nbut access in l2cap_sock_cleanup_listen() has unsafe lockless read.\n\n [Task 1]                         [Task 2 (hdev->workqueue)]\n l2cap_sock_release(parent)       l2cap_disconn_cfm\n   l2cap_sock_cleanup_listen        l2cap_conn_del\n     bt_accept_dequeue                l2cap_chan_del\n       lock_sock(sk)                    l2cap_sock_teardown_cb\n       bt_accept_unlink\n         bt_sk(sk)->parent = NULL\n       release_sock(sk) ----------------> lock_sock(sk)\n                                          parent = /* NULL */\n     lock_sock(sk) <--------------------- release_sock(sk)\n                                          sock_set_flag(sk, SOCK_ZAPPED)\n                                      l2cap_sock_close_cb\n                                        l2cap_sock_kill(sk)\n                                          l2cap_sock_put_chan\n     chan = READ l2cap_pi(sk)->chan         l2cap_pi(sk)->chan = NULL\n     l2cap_chan_hold_unless_zero            l2cap_put_chan(chan)\n       kref_get_unless_zero(&chan->ref)\n\nTask 1 may observe NULL which causes null-ptr-deref.\n\nFix the race by taking lock_sock() in l2cap_sock_kill() to\nsynchronize with l2cap_sock_cleanup_listen().  hold_unless_zero() is not\nneeded here, l2cap_pi(sk)->chan owns reference if it is non-NULL.\n\nClarify code comments vs. locking.(CVE-2026-90091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix potential UAF when reading bpf link info\n\nIn bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is\naccessed without holding any locks. If the prog is concurrently replaced\nvia bpf_link_update, the old prog can be freed, leading to a potential\nUAF issue.\n\nFix this by accessing link->prog under RCU protection to safely fetch\nthe pointer and guarantee its lifetime while reading its fields.(CVE-2026-90392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: reject login PDUs declaring more data than was received\n\nisert_login_recv_done() records how many bytes the HCA actually placed in\nthe login buffer, but nothing compares that against the length the login\nPDU's BHS declares.  isert_rx_login_req() copies min(login_req_len,\nMAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then\nreads the declared length back out of that buffer - for the first PDU in\niscsi_target_locate_portal(),\n\n\tpayload_length = ntoh24(login_req->dlength);\n\ttmpbuf = kmemdup_nul(login->req_buf, payload_length, GFP_KERNEL);\n\nand for the ones after it in iscsi_decode_text_input(), reached from\niscsi_target_do_login().\n\nlogin->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so\nan initiator that declares more than it sends reads off the end of it,\nbefore authentication and with the length under its control:\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80\n  Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167\n   __asan_memcpy+0x23/0x60\n   kmemdup_nul+0x43/0x80\n   iscsi_target_locate_portal+0x48d/0x1180\n   iscsi_target_login_thread+0x19a9/0x3350\n  Allocated by task 167:\n   __kmalloc_cache_noprof+0x158/0x370\n   iscsi_target_login_thread+0x971/0x3350\n  which belongs to the cache kmalloc-8k of size 8192\n  allocated 8192-byte region\n\nFalsifying the second login PDU instead reaches the other reader, on the\nsame buffer:\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80\n  Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50\n  Workqueue: isert_login_wq iscsi_target_do_login_rx\n   __asan_memcpy+0x23/0x60\n   kmemdup_nul+0x43/0x80\n   iscsi_decode_text_input+0xc6/0x11c0\n   iscsi_target_do_login+0x261/0x1470\n   iscsi_target_do_login_rx+0x51d/0x7d0\n\niscsit over TCP is not exposed: iscsit_get_login_rx() validates the\ndeclared length with iscsi_target_check_login_request() and then reads\nexactly that many bytes off the socket, so the declared length governs\nhow much arrives rather than how much is copied out of an already-filled\nbuffer.  isert does not call iscsi_target_check_login_request() at all.\n\nReject a login PDU whose declared DataSegmentLength exceeds what was\nreceived, in both paths that reach isert_rx_login_req():\nisert_get_login_rx() for the first login PDU and isert_login_recv_done()\nfor the ones after it.  dlength <= login_req_len is allowed because the\nreceived count can include up to three bytes of iSCSI padding.\n\nOnce the check is in place the copy out can no longer exceed the copy in:\nthe posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot\nexceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is\nlogin_req_len.\n\nLike the existing short-PDU check added by 29e7b925ae6d, the reject in\nisert_login_recv_done() returns without completing login_req_comp, so a\nmalformed subsequent PDU leaves the login to be torn down by the login\ntimer rather than failing immediately.  The first-PDU path returns an\nerror and fails straight away.\n\nReproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an\ninitiator that sends the real key=value payload while declaring 8193 in\nthe BHS, on the first login PDU and on the second in separate runs.  The\nreported read size tracks the declared value exactly; 16384 and 61440\nbehave the same.  Unpatched 3 of 3 runs report on each of the two paths,\npatched 0 of 3 on both, run alternately in a single session, and a normal\nlogin still completes on the patched build.(CVE-2026-90413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: reject PDUs declaring more data than was received\n\nisert_recv_done() hands each received PDU to the opcode handlers without\never looking at wc->byte_len, the number of bytes the HCA actually placed\nin the receive descriptor. The handlers then copy that many bytes - the\ndata-segment length the initiator declared in the BHS\n(ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) -\nout of the fixed-size descriptor:\n\n  isert_handle_iscsi_dataout():\n        sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc),\n                            unsol_data_len);\n  isert_handle_scsi_cmd():\n        sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents,\n                            isert_get_data(rx_desc), imm_data_len);\n\nBecause the declared length is never checked against wc->byte_len, an\ninitiator can declare a data segment larger than the bytes it actually\nsent (and larger than the descriptor) and cause an out-of-bounds read of\nthe receive buffer.\n\nNothing upstream of isert closes this door:\n\n  - __iscsit_check_dataout_hdr() bounds the inbound payload against\n    conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter,\n    used here for the inbound check.\n  - iscsi_set_connection_parameters() sets\n    ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength;\n    and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in\n    iscsi_check_acceptor_state(), so the value the initiator declares is\n    adopted verbatim (type range 512..16777215). The initiator effectively\n    raises its own ceiling.\n  - isert never clamps the negotiated value to its own fixed receive\n    descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and\n    the descriptor size are unrelated.\n\nThe imm_data_len == data_len path is more than an over-read: it aliases\nthe receive descriptor via sg_set_buf() and passes it to the backend as\nthe data source for the SCSI WRITE, so an over-declared length causes heap\ncontents past the descriptor to be written through the backend to the\nbacking store. The backend is the victim of the oversized scatterlist\nisert hands it, not the cause; no read-back of the written bytes was\ndemonstrated.\n\nTrigger: after login completes (full feature phase), an initiator that has\ndeclared a large TargetRecvDataSegmentLength and a FirstBurstLength that\npermits unsolicited/immediate data sends a PDU whose declared data-segment\nlength exceeds what was received. With KASAN:\n\n  BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0\n  Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25\n  Workqueue: ib-comp-wq ib_cq_poll_work\n  Call Trace:\n   sg_copy_buffer+0x150/0x1c0\n   isert_recv_done+0xba6/0x2390\n   __ib_process_cq+0xe1/0x390\n   ib_cq_poll_work+0x46/0x150\n\nisert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout()\n(ib_isert.c:1160), inlined through isert_rx_opcode().\n\nValidate wc->byte_len against the framing in isert_recv_done() before the\nPDU reaches any handler, and reinstate the connection if it is short.\nBecause the test compares without subtracting the header length, it also\nrejects PDUs shorter than the iSER and iSCSI headers, which would otherwise\nbe parsed out of stale descriptor contents. The login handler rejects PDUs\nshorter than ISER_HEADERS_LEN (commit 29e7b925ae6d ("IB/isert: Reject login\nPDUs shorter than ISER_HEADERS_LEN")) but does not bound the declared\nlength either; that is fixed in the next patch. The data handlers had no\nlength check at all.\n\nisert reads the data segment from a fixed offset: isert_get_data()\nreturns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for\nan AHS.  The bytes the handlers touch are therefore exactly\n[ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum\nagainst wc->byte_len bounds precisely the region that is read.  An AHS\nterm would only make the test stricter without bounding anything furth\n---truncated---(CVE-2026-90414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: validate thread record before delete key rebuild\n\nhfsplus_delete_cat() is called with str == NULL when the last open\nreference to an unlinked HFS+ hardlink backing inode is closed. In that\ncase, the function finds the catalog thread by CNID and rebuilds the\ncatalog key from thread.nodeName.\n\nThat reconstruction path reads thread.nodeName.length directly from the\ncatalog B-tree into fd.search_key and then copies length * 2 bytes into\nfd.search_key->cat.name.unicode. It does not first check that the found\nrecord is a thread record or that its size matches the thread name.\n\nA corrupted image can therefore provide an oversized thread name length\nand make hfs_bnode_read() write past the catalog search-key allocation.\n\nRead the CNID record through hfsplus_brec_read_cat(), which bounds the\nrecord read to sizeof(hfsplus_cat_entry) and verifies that a thread\nrecord's size exactly matches nodeName.length. Together, these checks\nensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread\nrecords before building the delete key from the validated thread name.\n\nShare the thread-record-type helper between hfsplus_find_cat() and\nhfsplus_delete_cat().(CVE-2026-93095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Preserve unit 0 on allocation failure\n\nhfi1_free_devdata() assumes that the device was inserted into the unit\ntable and unconditionally erases dd->unit. If xa_alloc_irq() fails, the\nzero-initialized unit remains zero, so full cleanup can remove an\nunrelated device from index 0.\n\nRelease only the rdmavt allocation and return immediately while the unit\ntable has not acquired the device.(CVE-2026-93103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rvt: Return NULL after port allocation failure\n\nrvt_alloc_device() deallocates the IB device when its port array cannot\nbe allocated but then returns the pointer to the released allocation.\nCallers treat any non-NULL value as valid and dereference it, resulting\nin a use-after-free.\n\nReturn NULL immediately after deallocation so callers can propagate the\nallocation failure.(CVE-2026-93104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux\n\nbpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the\nbpf_verifier_lock, but publishes the result through a plain store\nand re-checks it through a plain lockless load. Nothing orders\nthe stores initializing the struct btf inside btf_parse_vmlinux()\nagainst the store publishing the pointer: On a weakly ordered\narch, a concurrent first-time caller taking the lockless fast\npath could in principle observe the pointer before the parsed\ncontents are visible. The mutex_unlock() does not help such a\nreader given it only synchronizes with a later acquisition of the\nsame lock. Thus, publish the pointer with smp_store_release()\nand read it on the fast path with smp_load_acquire().\n\nAcquire semantics are needed rather than a dependency-ordered\nREAD_ONCE(): btf_parse_vmlinux() also populates globals outside\nthe returned object (e.g. bpf_ctx_convert.t). An address\ndependency would only order accesses performed through the\npointer and not cover other globals.(CVE-2026-93138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: quiesce input in hid_hw_stop() to prevent use-after-free\n\nA driver's probe calls hid_device_io_start() to enable input delivery,\nthen fails at a later initialization step and unwinds via hid_hw_stop().\nThe unwind frees struct hidraw via hidraw_disconnect() while in-flight\nHID reports may still be running on another CPU, dereferencing the\nfreed object through hidraw_report_event(). syzbot reports the\nresulting use-after-free for the corsair-psu HID driver.\n\nEdward Adam Davis posted a per-driver fix for corsair-psu that adds\nan explicit hid_device_io_stop() before hid_hw_stop() in the probe\nerror path ("hwmon: prevent packets from going to driver for probe",\n2026-04-28). Auditing the tree shows 15 drivers call\nhid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:\n\n  drivers calling hid_device_io_start() without a matching\n  hid_device_io_stop() before hid_hw_stop():\n    drivers/hwmon/corsair-psu.c       (fix posted by Edward)\n    drivers/hwmon/corsair-cpro.c\n    drivers/hwmon/nzxt-kraken3.c\n    drivers/hwmon/nzxt-smart2.c\n    drivers/hwmon/gigabyte_waterforce.c\n    drivers/hid/hid-logitech-dj.c\n    drivers/hid/hid-nintendo.c\n    drivers/hid/hid-mcp2221.c\n\nRoughly half of all callers of the API are exposed. Centralize the\nquiesce in hid_hw_stop() so callers do not have to remember the\nmatching stop: if a driver has left hdev->io_started true on entry,\ncall hid_device_io_stop() before hid_disconnect().\n\nFor the 7 drivers that already call hid_device_io_stop() correctly,\nhdev->io_started is false on entry, the guard short-circuits, and\nbehavior is unchanged.\n\nNo Fixes: tag because the affected drivers gained their\nhid_device_io_start() calls independently over years; the bug is a\nclass-wide API misuse rather than a regression from one commit.(CVE-2026-93189)","modified":"2026-10-01T02:00:07.332235665Z","published":"2026-09-30T13:47:24Z","upstream":["CVE-2026-64189","CVE-2026-89478","CVE-2026-89479","CVE-2026-89508","CVE-2026-89510","CVE-2026-89520","CVE-2026-89555","CVE-2026-89559","CVE-2026-89580","CVE-2026-89636","CVE-2026-89647","CVE-2026-89648","CVE-2026-89656","CVE-2026-89761","CVE-2026-89762","CVE-2026-89763","CVE-2026-89774","CVE-2026-89799","CVE-2026-89877","CVE-2026-89894","CVE-2026-89897","CVE-2026-89899","CVE-2026-89968","CVE-2026-89969","CVE-2026-89972","CVE-2026-89988","CVE-2026-90002","CVE-2026-90011","CVE-2026-90036","CVE-2026-90037","CVE-2026-90091","CVE-2026-90392","CVE-2026-90413","CVE-2026-90414","CVE-2026-93095","CVE-2026-93103","CVE-2026-93104","CVE-2026-93138","CVE-2026-93189"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4185"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64189"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89478"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89479"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89508"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89510"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89520"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89555"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89559"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89580"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89636"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89647"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89648"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89656"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89761"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89762"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89763"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89774"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89799"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89877"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89897"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89972"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89988"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90036"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90037"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90091"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90392"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90413"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93138"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93189"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-335.0.0.236.oe2203sp4"}]}],"ecosystem_specific":{"src":["kernel-5.10.0-335.0.0.236.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","perf-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm"],"aarch64":["bpftool-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","perf-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-4185.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}