{"id":"OESA-2026-3706","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:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhdlc_ppp: sync per-proto timers before freeing hdlc state\n\nEach PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp\nregisters a timer via timer_setup(). That struct ppp is the\nhdlc->state allocation, which detach_hdlc_protocol() frees with kfree()\nin both teardown paths: unregister_hdlc_device() and the re-attach inside\nattach_hdlc_protocol().\n\nThe ppp proto never registered a .detach callback, so\ndetach_hdlc_protocol() performs no timer synchronization before the\nkfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(),\nis partial (it does not wait for a running callback) and only runs on the\n->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A\nppp_timer callback already executing (blocked on ppp->lock) survives the\nkfree and then dereferences proto->state / ppp->lock in freed memory,\nleading to a use-after-free.\n\nFix this by adding a .detach helper that calls timer_shutdown_sync() on\nevery per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev)\nbefore kfree(hdlc->state), so timer_shutdown_sync()\nnow runs on both free paths.\ntimer_shutdown_sync() is used instead of timer_delete_sync() because the\nkeepalive path re-arms the timer through add_timer()/mod_timer() and\nshutdown blocks any re-activation during teardown.\n\nInitialize the per-protocol timers in ppp_ioctl() when the protocol is\nattached, and remove the now-redundant timer_setup() from ppp_start(), so\nthat the timers are initialized exactly once at attach time and\nppp_timer_release() never operates on uninitialized timer_list\nstructures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so\nstruct ppp's protos[i].timer is uninitialized garbage until the first\ntimer_setup(); without this init-at-attach, attaching the PPP protocol\nwithout ever bringing the device up would leave timer_shutdown_sync()\noperating on uninitialized memory in .detach. Moving the init out of\nppp_start() (which only runs on NETDEV_UP) into the attach path makes the\ninitialization unconditional and avoids initializing the same timer_list\ntwice.\n\nThis bug was found by static analysis.(CVE-2026-63803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparport: Fix race between port and client registration\n\nThe parport subsystem registers port devices before they are fully\ninitialised, resulting in a race condition where client drivers such\nas lp can attach to ports that are not completely initialised or even\nbeing torn down.\n\nWhen the port and client drivers are built as modules and loaded\naround the same time during boot, this occasionally results in a\ncrash.  I was able to make this happen reliably in a VM with a\nPC-style parallel port by patching parport_pc to fail probing:\n\n> --- a/drivers/parport/parport_pc.c\n> +++ b/drivers/parport/parport_pc.c\n> @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base,\n>  \tif (!p)\n>  \t\tgoto out3;\n>\n> -\tbase_res = request_region(base, 3, p->name);\n> +\tbase_res = NULL;\n>  \tif (!base_res)\n>  \t\tgoto out4;\n>\n\nand then running:\n\n    while true; do\n        modprobe lp & modprobe parport_pc\n\twait\n\trmmod lp parport_pc\n    done\n\nfor a few seconds.\n\nIn the long term I think port registration should be changed to put\nthe call to device_add() inside parport_announce_port(), but since the\nlatter currently cannot fail this will require changing all port\ndrivers.\n\nFor now, add a flag to indicate whether a port has been "announced"\nand only try to attach client drivers to ports when the flag is set.(CVE-2026-63942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Check for underflow in xfrm_state_mtu\n\nLeo Lin reported OOB write issue in esp component:\n\n  xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned\n  modulo-2^32 space using an attacker-influenced "header_len + authsize +\n  net_adj" subtracted from a small "mtu" argument. A nobody user can\n  install an IPv4 ESP tunnel SA with a large authentication key\n  (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc),\n  configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a\n  large value. When a single UDP datagram is then sent through the\n  tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and\n  esp_output() consumes it as a signed int via:\n\n        padto      = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached))\n        esp.tfclen = padto - skb->len   (assigned to int)\n\n  esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t\n  when passed to memset() inside esp_output_fill_trailer(), producing a\n  ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as\n  "Write of size 18446744073709551537 at addr ffff888...".\n\nCheck for underflow and return 1. This causes the sendmsg attempt to\nfail with ENETUNREACH.(CVE-2026-64009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: avoid double free of pool->stack on AQ init failure\n\notx2_pool_aq_init() frees pool->stack when mailbox sync or retry\nallocation fails, but leaves the pointer unchanged. Later,\notx2_sq_aura_pool_init() unwinds the partial setup through\notx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific\ncn20k_pool_aq_init() implementation has the same bug in\nits corresponding error path.\n\nSet pool->stack to NULL immediately after the local free so the shared\ncleanup path does not free the same stack again while cleaning up\npartially initialized pool state.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still present in\nv7.1-rc3.\n\nRuntime validation was not performed because reproducing this path\nrequires OcteonTX2/CN20K hardware.(CVE-2026-64222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix use-after-free of the discoverer in tipc_disc_rcv()\n\nbearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(),\nbut tipc_disc_rcv() still dereferences b->disc in RX softirq under\nrcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv).\n\nL2 bearers are safe thanks to the synchronize_net() in\ntipc_disable_l2_media(), but the UDP bearer defers that call to the\ncleanup_bearer() workqueue, so the discoverer is freed with no grace\nperiod:\n\n BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149)\n Read of size 8 at addr ffff88802348b728 by task poc_tipc/184\n <IRQ>\n  tipc_disc_rcv (net/tipc/discover.c:149)\n  tipc_rcv (net/tipc/node.c:2126)\n  tipc_udp_recv (net/tipc/udp_media.c:391)\n  udp_rcv (net/ipv4/udp.c:2643)\n  ip_local_deliver_finish (net/ipv4/ip_input.c:241)\n </IRQ>\n Freed by task 181:\n  kfree (mm/slub.c:6565)\n  bearer_disable (net/tipc/bearer.c:418)\n  tipc_nl_bearer_disable (net/tipc/bearer.c:1001)\n\nThe bearer is freed with kfree_rcu(); free the discoverer the same way.\nAdd an rcu_head to struct tipc_discoverer and free it and its skb from an\nRCU callback.\n\nBecause the RCU callback (tipc_disc_free_rcu) lives in module text, a\ncall_rcu() that is still pending when the tipc module is unloaded would\ninvoke a freed function. Add an rcu_barrier() to tipc_exit() after the\nbearer subsystem has been torn down, so all pending discoverer callbacks\nhave run before the module text goes away.\n\nReachable from an unprivileged user namespace: the TIPCv2 genl family is\nnetnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC\nand CONFIG_TIPC_MEDIA_UDP.(CVE-2026-64543)\n\nIn the Linux kernel, the following vulnerability has been resolved:\\n\\nKVM: x86: Check for invalid/obsolete root *after* making MMU pages available\\n\\nCheck for a \\"stale\\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \\"fine\\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages.\\n\\nNote, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \\"KVM: MMU: ignore zapped root pagetables\\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages.\\n\\nNote #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.(CVE-2026-64561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npppoe: reload header pointer after dev_hard_header()\n\npppoe_sendmsg() saves a pointer to the PPPoE header before calling\ndev_hard_header(). Device header callbacks are allowed to reallocate the\nskb head, invalidating pointers into it.\n\nThis can happen when a send is blocked in copy_from_user() while the first\nnon-Ethernet port is added to an empty team device. The team's delegated\nGRE header callback then expands the skb head. PPPoE subsequently writes\nsix bytes through the stale pointer into the freed head.\n\nReload the PPPoE header through the skb's network-header offset after\ndevice header creation. pskb_expand_head() updates that offset when it\nrelocates the head.(CVE-2026-68121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix GSO userspace truncation underflow\n\nOVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb\nlength in OVS_CB(skb)->cutlen. When a later userspace action segments a\nGSO skb, queue_gso_packets() reuses that delta for each smaller segment.\nA segment can then reach queue_userspace_packet() with cutlen greater\nthan skb->len, underflowing the length passed to skb_zerocopy().\n\nStore the maximum preserved length instead and bound each consumer\nagainst the current skb length. Use U32_MAX as the no-truncation\nsentinel so the value remains valid if skb geometry changes before a\nconsumer handles it.(CVE-2026-68123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmac802154: llsec: reject frames shorter than the authentication tag\n\nllsec_do_decrypt_auth() computes the associated-data length for the\nAEAD request as\n\n\tassoclen += datalen - authlen;\n\nwhere datalen is the number of bytes after the MAC header and authlen\n(4, 8 or 16) is the length of the authentication tag. Nothing verifies\nthat the frame actually carries at least authlen payload bytes. A\nsecured frame whose payload is shorter than the tag makes\ndatalen - authlen negative; assoclen is then passed to\naead_request_set_ad() as an unsigned value close to 4 GiB, so\ncrypto_aead_decrypt() walks far off the end of the scatterlist that\nonly spans the real frame.\n\nThe frame is fully attacker-controlled and reaches this path from any\nIEEE 802.15.4 peer in radio range. Reject frames whose payload is\nshorter than the authentication tag before the subtraction.\n\nDynamically reproduced on a KASAN kernel as a general-protection-fault\nin the AEAD scatterwalk, and the fix confirmed.(CVE-2026-68125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: slip: serialize receive against buffer reallocation\n\nsl_realloc_bufs() replaces rbuff and updates buffsize while holding\nsl->lock. slip_receive_buf() reads those fields and writes through rbuff\nwithout holding the lock.\n\nAn MTU change can therefore race with receive processing. An MTU shrink\ncan expose the new smaller rbuff with the old larger bound, causing an\nout-of-bounds write. A receive callback which already loaded the old\nrbuff can instead continue writing after that buffer has been freed.\n\nSerialize receive processing with sl_realloc_bufs() by holding sl->lock\nwhile consuming each receive batch.(CVE-2026-68143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatchdog: pretimeout: Fix UAF in watchdog_unregister_governor()\n\nWhen a watchdog governor is unregistered, it updates existing watchdog\ndevices that were using this governor by falling back to `default_gov`.\n\nIf the governor being unregistered is currently set as `default_gov`,\nthe `default_gov` is never cleared.  This leads to 2 use-after-free\nissues:\n1. New watchdog devices registered after this point will inherit the\n   dangling `default_gov`.\n2. Existing watchdog devices using the unregistered governor will have\n   their `wdd->gov` reassigned to the dangling `default_gov`.\n\nFix the UAF by clearing `default_gov` if it matches the governor being\nunregistered.(CVE-2026-68357)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate. smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Correct: [100, 200) allocated data, skip; [200, 400) hole, zero-fill. Current: [100, 300) skipped; [300, 400) zero-filled afterwards. The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.(CVE-2026-68388)\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\nieee802154: admin-gate legacy LLSEC dump operations\n\nIn net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table\nbuilds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,\nLLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which\nsets no .flags, so generic netlink runs them ungated. The modern\nnl802154 family admin-gates the equivalent reads via\nNL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.\n\nAny local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve\nthe "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev\nthat has an LLSEC key installed; the dump handler writes the raw\n16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied\nverbatim from struct ieee802154_llsec_key.key) into the reply.\nRecovering the AES key compromises 802.15.4 LLSEC link confidentiality\nand authenticity, since LLSEC uses CCM* and the same key authenticates\nand encrypts frames.\n\nImpact: any local uid with no capabilities can read the raw 16-byte\nAES-128 LLSEC key from the kernel keytable on any wpan netdev that has\nan administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY\ndump on the legacy IEEE802154_NL generic-netlink family.\n\nIntroduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but\nsetting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump\nentries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the\nmodern nl802154 family exposes their equivalents to unprivileged\nreaders by design (NL802154_CMD_GET_WPAN_PHY and\nNL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged\nusers" annotations).(CVE-2026-72049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-laptop: fix missing cleanups in init error path\n\ndell_init() initializes several resources after dell_setup_rfkill(),\nincluding the optional touchpad LED, keyboard backlight LED, battery\nhook, debugfs directory and dell-laptop notifier.\n\nIf a later LED or backlight registration fails, the error path only\ntears down the battery hook and rfkill resources. This leaves the\nnotifier, debugfs directory, keyboard backlight LED and optional\ntouchpad LED registered after dell_init() returns an error.\n\nAdd the missing cleanup calls before tearing down rfkill.(CVE-2026-72144)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nselinux: check connect-related permissions on TCP Fast Open\n\nSimilar to Landlock, SELinux was not updated when TCP Fast Open\nsupport was introduced to ensure connect-related permissions are\nchecked when using TCP Fast Open. Update its socket_sendmsg() hook to\ncall selinux_socket_connect() when MSG_FASTOPEN is passed.(CVE-2026-72243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix possible use after free\n\nIn dma_release_channel(), check chan->device->privatecnt after call\ndma_chan_put(). However, dma_chan_put() call dma_device_put() which could\nrelease the last reference of the device if the DMA provider is already\ngone and hence free it.\n\nFixes it by moving dma_chan_put() after the check.(CVE-2026-72476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Release the HW‑provided UAR index rather than the SW one\n\nFree the UAR index returned by the hardware.(CVE-2026-74296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost/net: complete zerocopy ubufs only once\n\nvhost-net initializes one ubuf_info per outstanding zerocopy TX\ndescriptor and hands it to the backend socket.  The networking stack may\nthen clone a zerocopy skb before all skb references are released.  For\nexample, batman-adv fragmentation reaches skb_split(), which calls\nskb_zerocopy_clone() and increments the same ubuf_info refcount.\n\nvhost_zerocopy_complete() currently treats every ubuf callback as a\ncompleted vhost descriptor.  It dereferences ubuf->ctx, writes the\ndescriptor completion state, and drops the vhost_net_ubuf_ref even when\nthe callback only releases a cloned skb reference.  A backend reset can\ntherefore wait for and free the vhost_net_ubuf_ref while another cloned\nskb still carries the same ubuf_info.  A later completion then\ndereferences the freed ubufs pointer.\n\nKASAN reports the stale completion as:\n\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0\n  vhost_zerocopy_complete\n  skb_copy_ubufs\n  __dev_forward_skb2\n  veth_xmit\n\nThe freed object was allocated from vhost_net_ioctl() while setting the\nbackend and freed through kfree_rcu()/kvfree_rcu_bulk after backend\nremoval, while delayed skb completion still reached\nvhost_zerocopy_complete().\n\nHonor the generic ubuf_info refcount before touching vhost state, and run\nthe vhost descriptor completion only for the final ubuf reference.  This\nmatches the msg_zerocopy_complete() ownership rule for cloned zerocopy\nskbs.(CVE-2026-74310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost/vdpa: validate virtqueue index in mmap and fault paths\n\nvhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a\nvirtqueue index for get_vq_notification(), but they do not validate\nthat the index is smaller than v->nvqs.\n\nThe ioctl path already performs both a bounds check and\narray_index_nospec(), but the mmap/fault path only checks that the\nindex fits in u16. This allows an out-of-range queue index to reach\ndriver-specific get_vq_notification() callbacks.\n\nFix this by extracting a unified vhost_vdpa_get_vq_notification()\nhelper that validates the queue index against v->nvqs and applies\narray_index_nospec() before calling the driver callback. Both the\nmmap and fault paths use this helper, and the bounds checking is\nconsolidated into a single location.\n\nFrom source inspection, the most defensible impact is out-of-bounds\naccess in the callback path, potentially leading to invalid PFN\nremaps and crash/DoS.(CVE-2026-74312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate fast symlink target during inode read\n\nocfs2_validate_inode_block() already rejects several inconsistent\nself-contained dinodes before they are exposed to the rest of the\nfilesystem.  Fast symlinks need the same treatment.\n\nA zero-cluster symlink is treated as a fast symlink and later read through\npage_get_link() and ocfs2_fast_symlink_read_folio().  That path uses\nstrnlen() on the inline payload and then copies len + 1 bytes into the\nfolio.  If a corrupt dinode stores an i_size that does not fit the inline\narea or omits the terminating NUL at i_size, that copy reads past the end\nof the inode block buffer.\n\nReject zero-cluster symlink dinodes whose i_size exceeds the inline\nfast-symlink capacity or whose inline payload is not NUL-terminated\nexactly at i_size when the inode block is validated.  This keeps malformed\nfast symlinks from reaching the read path.\n\nValidation reproduced this kernel report:\nKASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0\nRIP: 0033:0x7f5c6d859aa7\nRead of size 3905\nCall trace:\n  dump_stack_lvl+0x66/0xa0 (?:?)\n  print_report+0xce/0x630 (?:?)\n  ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x19f/0x330 (?:?)\n  kasan_report+0xe0/0x110 (?:?)\n  kasan_check_range+0x105/0x1b0 (?:?)\n  __asan_memcpy+0x23/0x60 (?:?)\n  filemap_read_folio+0x27/0xe0 (?:?)\n  filemap_read_folio+0x35/0xe0 (?:?)\n  do_read_cache_folio+0x138/0x230 (?:?)\n  __page_get_link+0x26/0x110 (?:?)\n  page_get_link+0x2e/0x70 (?:?)\n  vfs_readlink+0x15e/0x250 (?:?)\n  touch_atime+0x4d/0x370 (?:?)\n  do_readlinkat+0x186/0x200 (?:?)\n  do_user_addr_fault+0x65a/0x890 (?:?)\n  __x64_sys_readlink+0x46/0x60 (?:?)\n  do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)(CVE-2026-74350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix flex array size in struct nvme_ns_head\n\nstruct nvme_ns_head contains a flexible array member, current_path[],\nwhich is indexed using the NUMA node ID:\nhead->current_path[numa_node_id()]\n\nThe structure is currently allocated as:\nsize = sizeof(struct nvme_ns_head) +\n       (num_possible_nodes() * sizeof(struct nvme_ns *));\nhead = kzalloc(size, GFP_KERNEL);\n\nThis allocation assumes that NUMA node IDs are sequential and densely\npacked from 0 .. num_possible_nodes() - 1. While this assumption holds\non many systems, it is not always true on some architectures such as\npowerpc.\n\nOn some powerpc systems, NUMA node IDs can be sparse. For example:\nNUMA:\n  NUMA node(s):              6\n  NUMA node0 CPU(s):         80-159\n  NUMA node8 CPU(s):         0-79\n  NUMA node252 CPU(s):\n  NUMA node253 CPU(s):\n  NUMA node254 CPU(s):\n  NUMA node255 CPU(s):\n\nThat is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255\nIn this case: num_possible_nodes() = 6\n\nSo memory is allocated for only 6 entries in current_path[]. However,\nthe array is later indexed using the actual NUMA node ID. As a result,\naccesses such as:\nhead->current_path[8] or\nhead->current_path[252]\ngoes out of bounds, leading to the following KASAN splat:\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core]\nWrite of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997\n\nCPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy)\nHardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\nWorkqueue: async async_run_entry_fn\nCall Trace:\n[c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable)\n[c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c\n[c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220\n[c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120\n[c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core]\n[c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core]\n[c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core]\n[c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core]\n[c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0\n[c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10\n[c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640\n[c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290\n[c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18\n\nAllocated by task 1997 on cpu 1 at 35.928317s:\n\nThe buggy address belongs to the object at c00020003bda3000\n which belongs to the cache kmalloc-rnd-15-2k of size 2048\nThe buggy address is located 16 bytes to the right of\n allocated 1448-byte region [c00020003bda3000, c00020003bda35a8)\n\nThe buggy address belongs to the physical page:\n\nMemory state around the buggy address:\n c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n>c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc\n                                        ^\n c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n==================================================================\n\nFix this by allocating the flexible array using nr_node_ids instead\nof num_possible_nodes(). Since nr_node_ids represents the maximum\npossible NUMA node IDs, indexing current_path[] using numa_node_id()\nbecomes safe even on systems with sparse node IDs.(CVE-2026-74384)\n\nIn the Linux kernel, the following vulnerability has been resolved: vhost: reset the vring metadata cache on vring reconfiguration. vq->meta_iotlb[] caches the vhost_iotlb_map that backs each vring metadata region, and iotlb_access_ok() returns early on a cache hit, taking the hit as proof that the region has already been validated. The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOST_SET_VRING_ADDR replaces vq->desc, vq->avail and vq->used, nor when VHOST_SET_VRING_NUM changes the region sizes. With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time. Once the cache has been populated that deferred validation no longer runs, and vhost_vq_meta_fetch() keeps translating through the old mapping for an address the mapping no longer covers. vhost_copy_to_user() and vhost_copy_from_user() consume the result with __copy_to_user() and __copy_from_user(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps. This could lead to information disclosure, data corruption, or denial of service.(CVE-2026-74580)\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: vsock/virtio: avoid refilling the RX queue after teardown. Commit b917507e5ad9 ("vsock/virtio: stop workers during the .remove()") made the RX worker jump to its common exit when rx_run is clear. That exit still refills the RX queue when the buffer count is low, so work queued across virtio_vsock_vqs_del() can add buffers after the virtqueues have been deleted. This causes a KASAN slab-use-after-free error in virtqueue_add_sgs, leading to kernel panic.(CVE-2026-74613)\n\nIn the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more. A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set.(CVE-2026-74658)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings. tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it.(CVE-2026-74691)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: bounds-check buffer log item's dirty bitmap\n\nxlog_recover_do_reg_buffer() replays each dirty region described by a\nbuffer log item's bitmap into the buffer read for that item:\n\n\tmemcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT),\n\t\titem->ri_buf[i].iov_base,\n\t\tnbits << XFS_BLF_SHIFT);\n\nThe destination offset (bit/nbits, from the logged dirty bitmap) and the\nbuffer size (from the logged blf_len) are both attacker-controlled and\notherwise unrelated, yet the only thing bounding the copy is an ASSERT(),\nwhich compiles away on production kernels. A crafted image logging a\nsmall blf_len together with a bitmap bit past the end of that buffer\ndrives the memcpy() past the buffer's allocation, corrupting adjacent\nkernel heap during mount-time log recovery. This is reachable by anyone\nwho can get a crafted image mounted -- the malicious-filesystem threat\nmodel XFS already guards against elsewhere.\n\nTurn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery\nof the buffer with -EFSCORRUPTED, consistent with the validate-and-fail\nidiom already used in xlog_recover_do_inode_buffer() and\nxfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes\nSTATIC int and its three callers propagate the error.\n\nFound and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted\nimage trips a slab-out-of-bounds write before this change and fails\nrecovery cleanly with -EFSCORRUPTED after it.(CVE-2026-80536)\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: apparmor: fix potential UAF in aa_replace_profiles. The function aa_replace_profiles was accessing udata->size after calling aa_put_loaddata(udata), causing a potential UAF. Fixed this by saving the size to a local variable before dropping the reference.(CVE-2026-80619)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the tlclk driver's module cleanup process. The file_operations structure does not specify the .owner field, which could allow the module to be unloaded while user-space processes are still interacting with the device. Additionally, the tlclk_cleanup() function frees the alarm_events memory before ensuring that blocked processes in the waitqueue are fully awakened and that the switchover_timer has completed.(CVE-2026-80622)\n\nIn the Linux kernel, the netfilter synproxy module has an unaligned memory access issue in timestamp adjustment. Use get_unaligned_be32() and put_unaligned_be32() to safely read and write the timestamp fields. This prevents performance degradation due to unaligned memory access or even a crash on strict alignment architectures. This follows the implementation of timestamp parsing in the networking stack at tcp_parse_options() and synproxy_parse_options().(CVE-2026-80637)\n\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: xt_nat: reject unsupported target families. xt_nat SNAT and DNAT target handlers assume IP-family conntrack state is present and can dereference a NULL pointer when instantiated from an unsupported family through nft_compat. A bridge-family compat rule can therefore trigger a NULL-dereference in nf_nat_setup_info(). Reject non-IP families in xt_nat_checkentry() so unsupported targets cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT compat users and leave the runtime fast path unchanged.(CVE-2026-80664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: use READ_ONCE() for dev->driver in dev_has_sync_state()\n\ndev_has_sync_state() reads dev->driver twice without holding\ndevice_lock() -- once for the NULL check and once to dereference\n->sync_state. Some callers only hold device_links_write_lock, which\ndoesn't prevent a concurrent unbind from clearing dev->driver via\ndevice_unbind_cleanup().\n\nFix it by reading dev->driver exactly once with READ_ONCE(), pairing\nwith the WRITE_ONCE() in device_set_driver().(CVE-2026-80677)","modified":"2026-09-13T16:45:52.355946168Z","published":"2026-09-14T16:33:33Z","upstream":["CVE-2024-56603","CVE-2026-63803","CVE-2026-63942","CVE-2026-64009","CVE-2026-64222","CVE-2026-64543","CVE-2026-64561","CVE-2026-68121","CVE-2026-68123","CVE-2026-68125","CVE-2026-68143","CVE-2026-68357","CVE-2026-68388","CVE-2026-68426","CVE-2026-72049","CVE-2026-72144","CVE-2026-72243","CVE-2026-72476","CVE-2026-74296","CVE-2026-74310","CVE-2026-74312","CVE-2026-74350","CVE-2026-74384","CVE-2026-74580","CVE-2026-74587","CVE-2026-74613","CVE-2026-74658","CVE-2026-74691","CVE-2026-80536","CVE-2026-80558","CVE-2026-80619","CVE-2026-80622","CVE-2026-80637","CVE-2026-80664","CVE-2026-80677"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3706"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56603"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63803"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64543"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64561"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68121"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68123"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68143"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68357"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68426"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72049"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72144"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74312"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74384"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74580"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74587"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74613"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74658"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74691"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80536"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80558"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80619"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80622"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80664"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80677"}],"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-332.0.0.233.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","perf-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-332.0.0.233.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","perf-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3706.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"}]}