{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-339.0.0.240.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-339.0.0.240.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-339.0.0.240.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\nocfs2: clear extent cache after moving/defragmenting extents\n\nThe extent map cache can become stale when extents are moved or\ndefragmented, causing subsequent operations to see outdated extent flags. \nThis triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().\n\nThe problem occurs when:\n1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED\n2. ioctl(FITRIM) triggers ocfs2_move_extents()\n3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)\n4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()\n   which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)\n5. The extent map cache is not invalidated after the move\n6. Later write() operations read stale cached flags (0x2) but disk has\n   updated flags (0x0), causing a mismatch\n7. BUG_ON(!(rec-\u0026gt;e_flags \u0026amp; OCFS2_EXT_REFCOUNTED)) triggers\n\nFix by clearing the extent map cache after each extent move/defrag\noperation in __ocfs2_move_extents_range().  This ensures subsequent\noperations read fresh extent data from disk.(CVE-2025-40233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0026apos;t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n   the elevated refcount on the conduit\u0026apos;s kobject. Nominally, the OF and\n   non-OF paths should result in objects having identical reference\n   counts taken, and it is already suspicious that\n   dsa_dev_to_net_device() has a put_device() call which is missing in\n   dsa_port_parse_of(), but we can actually even verify that an issue\n   exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n   \u0026quot;before\u0026quot; and \u0026quot;after\u0026quot; applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u0026gt; /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0026apos;eno2\u0026apos; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0026apos;109\u0026apos; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n   it can get unregistered at any time, and DSA remains with a long-lived,\n   but in this case stale, cpu_dp-\u0026gt;conduit pointer. Holding the net\n   device\u0026apos;s underlying kobject isn\u0026apos;t actually of much help, it just\n   prevents it from being freed (but we never need that kobject\n   directly). What helps us to prevent the net device from being\n   unregistered is the parallel netdev reference mechanism (dev_hold()\n   and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\u0026quot;net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\u0026quot;), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0026apos;t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n   ports failed to probe, see commit 86f8b1c01a0a (\u0026quot;net: dsa: Do not\n   make user port errors fatal\u0026quot;), and the cpu_dp-\u0026gt;conduit pointers\n   remain valid.  I haven\u0026apos;t audited all call paths to see whether they\n   will actually use the conduit in lack of any user port, but if they\n   do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n   associated to, and we can get into a situation where we\u0026apos;ve moved all\n   user ports away from a conduit, thus no longer hold any reference to\n   it via the net device tracker. But we shouldn\u0026apos;t let it go nonetheless\n   - see the next change in relation to dsa_tree_find_first_conduit()\n   and LAG conduits which disappear.\n   We have to be prepared to return to the physical conduit, so the CPU\n   port must explicitly keep another reference to it. This is also to\n   say: the user ports and their CPU ports may not always keep a\n   reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0026apos;s kobject for the /sys/class/net/ entry, we don\u0026apos;t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0026apos;ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix out-of-bounds write in ocfs2_write_end_inline\n\nKASAN reports a use-after-free write of 4086 bytes in\nocfs2_write_end_inline, called from ocfs2_write_end_nolock during a\ncopy_file_range splice fallback on a corrupted ocfs2 filesystem mounted on\na loop device.  The actual bug is an out-of-bounds write past the inode\nblock buffer, not a true use-after-free.  The write overflows into an\nadjacent freed page, which KASAN reports as UAF.\n\nThe root cause is that ocfs2_try_to_write_inline_data trusts the on-disk\nid_count field to determine whether a write fits in inline data.  On a\ncorrupted filesystem, id_count can exceed the physical maximum inline data\ncapacity, causing writes to overflow the inode block buffer.\n\nCall trace (crash path):\n\n   vfs_copy_file_range (fs/read_write.c:1634)\n     do_splice_direct\n       splice_direct_to_actor\n         iter_file_splice_write\n           ocfs2_file_write_iter\n             generic_perform_write\n               ocfs2_write_end\n                 ocfs2_write_end_nolock (fs/ocfs2/aops.c:1949)\n                   ocfs2_write_end_inline (fs/ocfs2/aops.c:1915)\n                     memcpy_from_folio     \u0026lt;-- KASAN: write OOB\n\nSo add id_count upper bound check in ocfs2_validate_inode_block() to\nalongside the existing i_size check to fix it.(CVE-2026-43075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Limit XDomain response copy to actual frame size\n\ntb_xdomain_copy() copies req-\u0026gt;response_size bytes from the received\npacket buffer regardless of the actual frame size.  When a short\nresponse arrives, this reads past the valid frame data in the DMA\npool buffer into stale contents from previous transactions.\n\nUse the minimum of frame size and expected response size for the\ncopy length.(CVE-2026-53146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: update file PMD counter before folio_put()\n\n__split_huge_pmd_locked() updates the file/shmem RSS counter after\ndropping the PMD mapping\u0026apos;s folio reference.  If folio_put() drops the last\nreference, mm_counter_file() can later read freed folio state via\nfolio_test_swapbacked().\n\nMove the counter update before folio_put().(CVE-2026-53189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: reject short frames before parsing\n\nA BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the\npacket type byte immediately and, for control packets, reads the control\nopcode and setup UUID-size byte before proving that those bytes are\npresent. bnep_rx_control() also dereferences the control opcode without\nrejecting an empty control payload.\n\nUse skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL\nreturn gates each dereference. Split the control handler so the frame\npath can pass an opcode that has already been pulled, and keep the\nbyte-buffer wrapper for extension control payloads.\n\nFor BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the\nsetup payload. struct bnep_setup_conn_req carries destination and source\nservice UUIDs after that byte, each uuid_size bytes, so the parser now\ndocuments that tuple explicitly instead of leaving the pull length as an\nopaque multiplication.\n\nValidation reproduced this kernel report:\nKASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790\nThe buggy address belongs to the object at ffff88800c0f7908 which belongs\nto the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes to the right of allocated 1-byte\nregion [ffff88800c0f7908, ffff88800c0f7909)\nRead of size 1\nCall trace:\n  dump_stack_lvl+0xb3/0x140 (?:?)\n  print_address_description+0x57/0x3a0 (?:?)\n  bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)\n  print_report+0xb9/0x2b0 (?:?)\n  __virt_addr_valid+0x1ba/0x3a0 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  kasan_addr_to_slab+0x21/0x60 (?:?)\n  kasan_report+0xe0/0x110 (?:?)\n  process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)\n  worker_thread+0x65c/0xe40 (?:?)\n  __kthread_parkme+0x184/0x230 (?:?)\n  kthread+0x35e/0x470 (?:?)\n  _raw_spin_unlock_irq+0x28/0x50 (?:?)\n  ret_from_fork+0x586/0x870 (?:?)\n  __switch_to+0x74f/0xdc0 (?:?)\n  ret_from_fork_asm+0x1a/0x30 (?:?)(CVE-2026-53253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: validate skb length in MCC handlers\n\nThe RFCOMM MCC handlers cast skb-\u0026gt;data to protocol-specific structs\nwithout validating skb-\u0026gt;len first. A malicious remote device can send\ntruncated MCC frames and trigger out-of-bounds reads in these handlers.\n\nFix this by using skb_pull_data() to validate and access the required\ndata before dereferencing it.\n\nrfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows\n1-byte RPN requests. Handle this by validating only the DLCI byte first,\nand validating the full struct only when len \u0026gt; 1.(CVE-2026-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack: destroy stale expectfn expectations on unregister\n\nNAT helpers such as nf_nat_h323 store a raw pointer to module text in\nexp-\u0026gt;expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()\nonly unlinks the callback descriptor and never walks the expectation table,\nso an expectation pending at module removal survives with a dangling\nexp-\u0026gt;expectfn into freed module text.\n\nWhen the expected connection arrives, init_conntrack() invokes\nexp-\u0026gt;expectfn(), now a stale pointer into the unloaded module. Reproduced\non a KASAN build by loading the H.323 helpers, creating a Q.931\nexpectation, unloading nf_nat_h323, then connecting to the expected port:\n\n Oops: int3: 0000 [#1] SMP KASAN NOPTI\n RIP: 0010:0xffffffffa06102d1\n  init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)\n  nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)\n  ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)\n  nf_hook_slow (net/netfilter/core.c:619)\n  __ip_local_out (net/ipv4/ip_output.c:120)\n  __tcp_transmit_skb (net/ipv4/tcp_output.c:1715)\n  tcp_connect (net/ipv4/tcp_output.c:4374)\n  tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)\n  __sys_connect (net/socket.c:2167)\n Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]\n\nReaching the dangling state requires CAP_SYS_MODULE in the initial user\nnamespace to remove a NAT helper that still has live expectations, so this\nis a robustness fix; leaving an expectation pointing at freed text is wrong\nregardless.\n\nAdd nf_ct_helper_expectfn_destroy(), which walks the expectation table and\ndrops every expectation whose -\u0026gt;expectfn matches the descriptor being torn\ndown. Call it from each NAT helper\u0026apos;s exit path after the existing RCU grace\nperiod, so no expectation outlives the code it points at and no extra\nsynchronize_rcu() is introduced. With the fix, the same reproducer runs to\ncompletion without the Oops.(CVE-2026-53349)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: reject direct userspace writes to reserved $LX* xattrs\n\nNTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL\npermission metadata and reloads them into i_uid, i_gid and i_mode\nfrom ntfs_get_wsl_perm().\n\nBecause the empty-prefix xattr handler also lets file owners call\nsetxattr() on these names directly, an unprivileged writer on a\nwritable ntfs3 mount can plant root ownership and S_ISUID on their own\nfile and gain euid 0 after inode reload.\n\nReject direct userspace writes to the reserved $LX* names. Internal\nntfs3 metadata updates are unchanged because ntfs_save_wsl_perm()\nwrites them via ntfs_set_ea() directly.\n\n[(CVE-2026-63833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F3A keymap to the GPIO count\n\nrmi_f3a_initialize() takes the GPIO count from the device query register\n(f3a-\u0026gt;gpio_count = buf \u0026amp; RMI_F3A_GPIO_COUNT, range 0..127).\nrmi_f3a_map_gpios() then allocates gpio_key_map with\nmin(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but\nrmi_f3a_attention() iterates the full gpio_count and dereferences\ngpio_key_map[i], and input-\u0026gt;keycodemax is set to the full gpio_count\nwhile input-\u0026gt;keycode points at the 6-entry allocation.\n\nA device that reports gpio_count \u0026gt; 6 therefore causes an out-of-bounds\nread of gpio_key_map[] on every attention interrupt, and out-of-bounds\naccesses through the input core\u0026apos;s default keymap ioctls: EVIOCGKEYCODE\nreads past the buffer (leaking adjacent slab memory to user space) and\nEVIOCSKEYCODE writes a caller-controlled value past it, for any process\nable to open the evdev node, since input_default_getkeycode() and\ninput_default_setkeycode() only bound the index against keycodemax.\n\nSize the keymap for the full gpio_count. The mapping loop is unchanged:\nit still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)\nentries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)\nand are skipped when reporting.(CVE-2026-64277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: appleir: fix UAF on pending key_up_timer in remove()\n\nappleir_remove() runs hid_hw_stop() before timer_delete_sync().\nhid_hw_stop() synchronously unregisters the HID input device via\nhid_disconnect() -\u0026gt; hidinput_disconnect() -\u0026gt; input_unregister_device(),\nwhich drops the last reference and frees the underlying input_dev when\nno userspace handle holds it open.\n\nkey_up_tick() reads appleir-\u0026gt;input_dev and calls input_report_key() /\ninput_sync() on it.  The timer is armed from appleir_raw_event() with\na HZ/8 (~125 ms) timeout on every keydown and key-repeat report.  If a\nkey was pressed shortly before the device is disconnected, the timer\ncan fire after hid_hw_stop() has freed input_dev but before the\nteardown drains it.\n\nA simple reorder is not sufficient.  Putting the timer drain first\nstill leaves a window where a USB URB completion (raw_event) running\nduring hid_hw_stop() can call mod_timer() and re-arm the timer, which\nthen fires after hidinput_disconnect() has freed input_dev.  The same\nURB-completion window also lets raw_event() reach key_up(), key_down()\nand battery_flat() directly, all of which dereference\nappleir-\u0026gt;input_dev.\n\nIntroduce a \u0026apos;removing\u0026apos; flag on struct appleir, gated by the existing\nspinlock.  appleir_remove() sets the flag under the lock and then\nshuts down the timer with timer_shutdown_sync(), which both drains any\nin-flight callback and permanently disables further mod_timer() calls.\nappleir_raw_event() and key_up_tick() bail out early if the flag is\nset, so no path can arm or run the timer, or dereference\nappleir-\u0026gt;input_dev, after remove() has started tearing down.\n\nThe keyrepeat and flatbattery branches of appleir_raw_event()\npreviously called into the input layer without holding the spinlock;\ntake it now so the flag check is well-defined.  This incidentally\ncloses a pre-existing read-side race on appleir-\u0026gt;current_key in the\nkeyrepeat branch.\n\nThis bug is structurally a sibling of commit 4db2af929279 (\u0026quot;HID:\nappletb-kbd: fix UAF in inactivity-timer cleanup path\u0026quot;) and has been\npresent since the driver was introduced.(CVE-2026-64363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation}\n\nIn do_action()\u0026apos;s UpdateRecordDataRoot (fslog.c:3489) and\nUpdateRecordDataAllocation (fslog.c:3697) cases, the memmove\ndestination is `Add2Ptr(e, le16_to_cpu(e-\u0026gt;view.data_off))`,\nwhere e-\u0026gt;view.data_off comes from an on-disk NTFS_DE inside\nan INDEX_ROOT or INDEX_BUFFER.  Neither case validates\nview.data_off + dlen against e-\u0026gt;size; the existing\ncheck_if_index_root / check_if_alloc_index helpers walk the\nentry chain and validate the entry\u0026apos;s offset, but not its\ninternal view fields.\n\nThe neighbouring read sites (e.g., fs/ntfs3/index.c when\niterating view entries) check view.data_off + view.data_size\n\u0026lt;= e-\u0026gt;size.  Apply the same bound at the two memmove sites.\n\nReproduced under UML+KASAN on mainline 8d90b09e6741 via\npr_warn-only probe instrumentation: with view.data_off forced\nto 0xFFFC, the memmove writes 32 bytes past the end of the\nNTFS_DE.\n\nThis is similar in shape to Pavitra Jha\u0026apos;s 2026-05-02 patch\n\u0026quot;fs/ntfs3: prevent oob in case UpdateRecordDataRoot\u0026quot;\n(\u0026lt;(CVE-2026-64532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket\n\nsmc_cdc_rx_handler() looks up the connection by token under the link\ngroup\u0026apos;s conns_lock, drops the lock, and then dereferences conn and the\nsmc_sock derived from it, ending in sock_hold(\u0026amp;smc-\u0026gt;sk) inside\nsmc_cdc_msg_recv(). No reference is held across the lock release.\n\nThe only reference pinning the socket while the connection is\ndiscoverable in the link group is taken in smc_lgr_register_conn()\n(sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both\nunder conns_lock. Once the handler drops conns_lock, a concurrent\nclose() -\u0026gt; smc_release() -\u0026gt; smc_conn_free() -\u0026gt; smc_lgr_unregister_conn()\ncan drop that reference and free the smc_sock, so the handler\u0026apos;s later\nsock_hold() runs on freed memory:\n\n  WARNING: lib/refcount.c:25 at refcount_warn_saturate\n  Workqueue: rxe_wq do_work\n   refcount_warn_saturate (lib/refcount.c:25)\n   smc_cdc_msg_recv (net/smc/smc_cdc.c:430)\n   smc_cdc_rx_handler (net/smc/smc_cdc.c:502)\n   smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445)\n   tasklet_action_common (kernel/softirq.c:938)\n   handle_softirqs (kernel/softirq.c:622)\n  Kernel panic - not syncing: panic_on_warn set\n\nOnly SMC-R is affected. The SMC-D receive tasklet is stopped by\ntasklet_kill(\u0026amp;conn-\u0026gt;rx_tsklet) in smc_conn_free() before the connection\nis unregistered, so it cannot run concurrently with the free.\n\nTake the socket reference while still holding conns_lock, so the\nregistration reference can no longer be the last one, and drop it once\nthe handler is done.(CVE-2026-64541)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: validate firmware patch bounds\n\nrtlbt_parse_firmware() copies patch_length - 4 bytes before appending the\nfirmware version. A malformed firmware patch shorter than the version field\ncan make this subtraction underflow and turn the copy into an oversized\nread and write during Bluetooth setup.\n\nThe existing patch_offset + patch_length check can also wrap on 32-bit\narchitectures. Validate the patch length and range without arithmetic\noverflow before allocating or copying the patch.(CVE-2026-68479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set\n\nWhen a USB audio endpoint requests full packet transfers via the fill_max\ndescriptor flag, data_ep_set_params() promotes ep-\u0026gt;curpacksize to\nep-\u0026gt;maxpacksize. However, maxsize is left at the original sample-rate\nderived value.\n\nSince u-\u0026gt;buffer_size is allocated as maxsize * packets, the resulting\nDMA buffer is far too small for the requested transfer length. When the\nUSB host controller streams up to curpacksize bytes per packet, it writes\npast the end of the buffer via DMA, corrupting kernel heap memory.\n\nUpdate maxsize to curpacksize when fill_max is set so that the allocated\nDMA buffer size matches the actual transfer request size.\n\n[ changed to reassign maxsize only when ep-\u0026gt;fill_max is set -- tiwai ](CVE-2026-74498)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: validate numbered report payloads\n\nWhen hidp_get_raw_report() waits for a numbered report,\nhidp_process_data() compares the expected report number with skb-\u0026gt;data[0].\nA connected HIDP peer can reply with only a DATA transaction header,\nleaving the skb empty after the header is removed.\n\nKMSAN reports an uninitialized-value use in hidp_session_run(), with the\nvalue originating in __alloc_skb() through vhci_write(). The transaction\nheader checks remove the empty-frame reports, but this report remains until\nthe payload check is added.\n\nThe comparison can also consume a peer-controlled byte beyond the declared\nL2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made\nthe current code accept that byte as report ID 1 and complete\nHIDIOCGFEATURE with a zero-byte result. With this change the malformed\nresponse is rejected with -EIO, while a subsequent valid response still\nsucceeds.\n\nRequire a payload byte before comparing a numbered report ID. Unnumbered\nreports continue to accept an empty payload.(CVE-2026-74507)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: reject frames without a transaction header\n\nhidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb-\u0026gt;data[0]\nbefore checking that the L2CAP SDU contains a transaction header. A\nconnected HIDP peer can send an empty basic-mode SDU and make both paths\nuse an uninitialized byte from skb tailroom.\n\nKMSAN reports the use in hidp_session_run(), with the uninitialized value\noriginating in __alloc_skb() through vhci_write(). The control path\nproduces two reports and the interrupt path produces one.\n\nThe byte can also be controlled by a malformed lower-layer packet. If an\nHCI ACL packet contains an L2CAP PDU with a declared zero-length payload\nfollowed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb-\u0026gt;len to\nthe declared PDU length before dispatch. The current HIDP path nevertheless\nconsumes the extra byte as HIDP_TRANS_HID_CONTROL |\nHIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this\nchange, the same packet is discarded and a subsequent feature report\nrequest succeeds.\n\nPull the transaction header with skb_pull_data() and discard frames that\ndo not contain it.(CVE-2026-74508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: clear suppressed fib6 rule result\n\nfib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(),\nbut leaves res-\u0026gt;rt6 pointing at the released rt6_info.\n\nIf no later rule supplies a replacement, fib6_rule_lookup() still sees\nres.rt6 and returns that stale dst to its caller. A suppressing rule can\ntherefore leak a released route back to rt6_lookup(), and the next put\nhits rcuref_put_slowpath() from dst_release().\n\nClear res-\u0026gt;rt6 when suppressing the route so suppressed lookups fall\nthrough to the null dst instead of reusing the released one.(CVE-2026-74581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_route: fix fastmap use-after-free on filter\n\nThe route4 classifier maintains a 16-slot fastmap cache that stores raw\nstruct route4_filter pointers indexed by (id, iif). The reader\n(route4_classify) populates this cache via route4_set_fastmap() for every\nclassified packet that hits a filter. The writer (route4_delete,\nroute4_change) clears the cache via route4_reset_fastmap() before\nRCU-deferred kfree of the filter.\n\nThis creates a UAF race:\n 1. Reader walks the RCU-protected bucket chain, finds filter f\n 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work()\n 3. Reader calls route4_set_fastmap() and writes f into the cache\n    *after* the writer\u0026apos;s reset, caching a pointer about to be freed\n 4. After the RCU grace period, kfree(f) executes\n 5. Next classified packet on the same (id, iif) tuple hits the stale\n    fastmap entry and reads f-\u0026gt;res from freed memory\n\nReproduced with an mdelay(100) accelerator in route4_set_fastmap() and a\nconcurrent add/delete stress test (provided by both zdi and Santosh).\nBoth triggered KASAN slab-use-after-free reports in the route4 fastmap\npaths.\n\nFix:\nIntroduce a per-filter boolean dying flag to suppress stale fastmap\nrepublishing by in-flight readers.(CVE-2026-74583)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent in6_dev_get() from resurrecting inet6_dev\n\nin6_dev_get() reads dev-\u0026gt;ip6_ptr under RCU and then unconditionally\nincrements its refcount. Device teardown can clear the pointer and drop\nthe last reference between these operations. The increment then\nresurrects an object whose RCU free has already been queued, so callers\ncan use it after it is freed.\n\nUse refcount_inc_not_zero() and return NULL when the object has already\nreached zero. RCU keeps the memory accessible through the attempted\nreference acquisition, and a successful increment pins the object for\nthe caller.\n\nAn independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3)\nkernel reproduced the invalid reference acquisition as UID 1000:\n\n  refcount_t: addition on 0; use-after-free.\n  ip6_mc_source+0xef4/0x17e0\n\nIt was followed by the corresponding reference underflow in\nip6_mc_source(). The supplied trace from the same unpatched revision\nadditionally shows the access after the RCU read-side section ends:\n\n  BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0\n  Write of size 8 at addr ffff888015b50240 by task poc/1219\n\nBug found and triaged by OpenAI Security Research and\nvalidated by Trail of Bits.(CVE-2026-74630)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: skip hash tables in u32_bind_class()\n\nu32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode\nthrough the walker callback. u32_bind_class() unconditionally casts the\npassed fh to tc_u_knode and accesses \u0026amp;n-\u0026gt;res, so when fh is actually a\ntc_u_hnode, which has no tcf_result member, this results in a\nslab-out-of-bounds read of res-\u0026gt;classid in tc_cls_bind_class().\n\nThe issue can be reproduced with the following commands:\n\n    tc qdisc add dev lo root handle 1: hfsc\n    tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit\n    tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1\n    tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit\n\nFix this by skipping hash tables via the TC_U32_KEY(handle) check.(CVE-2026-74739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: strip GSO state from fragments before reassembly\n\nA virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark\nan IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.\ninet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first\nfragment\u0026apos;s skb as the head of the reassembled datagram, including its\nshinfo-\u0026gt;gso_size/gso_type/gso_segs, and chain the remaining fragments\non frag_list with whatever linear/paged layout they arrived with.\n\nAfter ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the\nreassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and\nthe next software segmentation point - udp_rcv_segment() on local\ndelivery, validate_xmit_skb(), or the ip_finish_output_gso() slow\npath - hands it to skb_segment(). skb_segment()\u0026apos;s frag_list walk\nassumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to\na tap by an unprivileged user in its own userns are enough:\n\n  kernel BUG at net/core/skbuff.c:4899!\n  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n  CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2\n  RIP: 0010:skb_segment+0x20ca/0x48b0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __udp_gso_segment+0x29a/0x27d0\n   udp4_ufo_fragment+0x458/0x6c0\n   inet_gso_segment+0x429/0x1340\n   skb_mac_gso_segment+0x233/0x4f0\n   __skb_gso_segment+0x308/0x660\n   udp_queue_rcv_skb+0x440/0xad0\n   udp_unicast_rcv_skb+0xc7/0x2c0\n   udp_rcv+0x16ce/0x2260\n   ip_protocol_deliver_rcu+0x197/0x2d0\n   ip_local_deliver+0x430/0x690\n   ip_rcv+0x16f/0x1f0\n   __netif_receive_skb_one_core+0x15e/0x1c0\n   __netif_receive_skb+0x1e/0x110\n   netif_receive_skb+0xf6/0x5c0\n   tun_rx_batched.isra.0+0x3ab/0x790\n   tun_get_user+0x17c3/0x3550\n   tun_chr_write_iter+0xba/0x1b0\n   vfs_write+0x646/0x1130\n   \u0026lt;/TASK\u0026gt;\n  Kernel panic - not syncing: Fatal exception in interrupt\n\nThis runs with BH disabled, so it is a panic rather than an oops. The\nsame is reachable with CAP_NET_RAW in a netns where a defrag point\nprecedes a GSO point, and from a guest whose VMM forwards\nvirtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by\ncommit 3dcbdb134f32 (\u0026quot;net: gso: Fix skb_segment splat when splitting\ngso_size mangled skb having linear-headed frag_list\u0026quot;) and by\ncommit 9e4b7a99a03a (\u0026quot;net: gso: fix panic on frag_list with mixed head\nalloc types\u0026quot;) do not cover it: page-backed heads skip them, and kmalloc\nheads skip them when gso_size == skb_headlen(head), which the sender\ncontrols.\n\nAn skb entering a frag queue is an IP fragment by definition and\ncannot legitimately carry GSO state: GRO does not merge fragments and\nthe stack segments before it fragments, so only untrusted sources are\naffected. This has been reachable since\ncommit f43798c27684 (\u0026quot;tun: Allow GSO using virtio_net_hdr\u0026quot;), the first\npath that let userspace attach GSO metadata to an IP fragment. Reset\nthe GSO fields of every fragment as it is queued, in\ninet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and\n6lowpan reassembly share; then neither the head nor the frag_list\nmembers of the reassembled skb carry them (the members matter too:\nthe ip_do_fragment()/ip6_fragment() fast paths send them out as they\nare). The head may remain CHECKSUM_PARTIAL; that is already accepted\non receive and resolved by skb_checksum_help() in\nip_do_fragment()/ip6_fragment() on forward.\n\nTested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer\nabove, two further IPv4 frag_list geometries that reach\nBUG_ON(i \u0026gt;= nfrags) and BUG_ON(!list_skb-\u0026gt;head_frag), and an IPv6\nfragment-header variant (udp6_ufo_fragment()) each panic the unpatched\nkernel; with this patch all four datagrams are delivered intact and\nnothing is logged.(CVE-2026-80590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: re-fetch eth header after route_shortcircuit()\n\nBefore route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb).\n\nInside route_shortcircuit(), pskb_may_pull() can be called, which may\nreallocate skb-\u0026gt;head.\n\nIn this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to\nfreed memory, leading to a use-after-free when dereferencing eth-\u0026gt;h_dest.\n\nFix this by updating eth = eth_hdr(skb) after calling route_shortcircuit().(CVE-2026-80681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: do not propagate one-packet flag to synced conns\n\nSynced connections can be created before their destination exists. When\nthe destination is later added, ip_vs_bind_dest() copies connection flags\nfrom the destination into cp-\u0026gt;flags.\n\nIP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced\nconnection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed,\nexpiry can treat it as a one-packet connection and skip unlinking the\nexisting conn_tab node, leaving stale hash nodes pointing at a freed\nstruct ip_vs_conn.\n\nDrop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced\nconnections.(CVE-2026-80714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nslip: fix use-after-free in sl_sync()\n\nslip_devs[] stores bare net_device pointers and takes no reference on\nthem.  sl_sync() and sl_alloc() walk that table from slip_open() under\nrtnl_lock(), while an entry is dropped by sl_free_netdev(), which\nsl_setup() installs as dev-\u0026gt;priv_destructor.\n\npriv_destructor is called from netdev_run_todo(), which deliberately\nruns with the RTNL semaphore released so that it can sleep while waiting\nfor the device refcount to drop:\n\n\t/* Snapshot list, allow later requests */\n\tlist_replace_init(\u0026amp;net_todo_list, \u0026amp;list);\n\n\t__rtnl_unlock();\n\t...\n\t\tif (dev-\u0026gt;priv_destructor)\n\t\t\tdev-\u0026gt;priv_destructor(dev);\t/* slip_devs[i] = NULL */\n\t\tif (dev-\u0026gt;needs_free_netdev)\n\t\t\tfree_netdev(dev);\n\t\t...\n\t\t/* Free network device */\n\t\tkobject_put(\u0026amp;dev-\u0026gt;dev.kobj);\n\nSo rtnl_lock() does not serialise slip_open() against the teardown at\nall.  sl_sync() can load slip_devs[i] while the entry is still published\nand dereference it after netdev_run_todo() has run the destructor and\nreleased the device:\n\n  CPU0 (slip_open)                 CPU1 (slip_close)\n                                   unregister_netdev()\n                                     rtnl_unlock()\n                                       netdev_run_todo()\n                                         __rtnl_unlock()\n  rtnl_lock()\n  sl_sync()\n    dev = slip_devs[i]\n                                         priv_destructor(dev)\n                                           slip_devs[i] = NULL\n                                         kobject_put(\u0026amp;dev-\u0026gt;dev.kobj)\n                                           /* dev is freed */\n    sl = netdev_priv(dev)\n    if (sl-\u0026gt;tty || sl-\u0026gt;leased)     /* use-after-free */\n\n  BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline]\n  BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806\n  Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506\n\n  CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\n  Call Trace:\n   sl_sync drivers/net/slip/slip.c:730 [inline]\n   slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806\n   tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433\n   tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564\n   tiocsetd drivers/tty/tty_io.c:2428 [inline]\n   tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712\n\n  Allocated by task 6502:\n   alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719\n   sl_alloc drivers/net/slip/slip.c:756 [inline]\n   slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817\n   tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433\n   tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564\n\n  Freed by task 6497:\n   device_release+0xa2/0x240 drivers/base/core.c:2507\n   kobject_put+0x179/0x280 lib/kobject.c:729\n   netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509\n   slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906\n   tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456\n   tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614\n   tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782\n   tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860\n\nCommit e58c19124189 (\u0026quot;slip: Fix use-after-free Read in slip_open\u0026quot;) fixed\na different source of stale entries - a device left in slip_devs[] after\nslip_open() freed it on the registration error path - and does not\naddress this race, which is why the report survives it.\n\nDrop the entry from ndo_uninit instead.  unregister_netdevice() calls\nndo_uninit under RTNL, before the device is queued to netdev_run_todo(),\nso an entry that sl_sync() can still see while holding RTNL belongs to a\ndevice that cannot be freed until RTNL is dropped.  sl_free_netdev()\nstays only for the slip_open() error path, where register_netdevice()\nmay have failed before ndo_init and ndo_uninit is then not called\neither.  Both running for the same device is harmless: the\n---truncated---(CVE-2026-81001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxdp: fix zero-copy frame layout\n\nxdp_convert_zc_to_xdp_frame() clones an XSK packet into an order-0 page\nand advertises PAGE_SIZE as its frame size.  It allows the copied frame\nto occupy the page tail needed by skb_shared_info and records zero\nheadroom even when metadata separates the frame header from packet data.\nAn AF_XDP zero-copy packet redirected through cpumap can therefore make\nthe skb overlap skb_shared_info or place it beyond the allocated page.\n\nLimit the copied layout to SKB_WITH_OVERHEAD(PAGE_SIZE) and include the\nmetadata length in frame headroom.  Redirect callers already handle a\nNULL conversion result.\n\nBUG: KASAN: slab-out-of-bounds in skb_gro_receive\nWrite of size 4 at addr ffff88800cf37004 by task cpumap/1/map:1/146\nCall Trace:\n skb_gro_receive (net/core/gro.c:174)\n udp_gro_receive (net/ipv4/udp_offload.c:812)\n inet_gro_receive (net/ipv4/af_inet.c:1539)\n dev_gro_receive (net/core/gro.c:515)\n gro_receive_skb (net/core/gro.c:633)\n cpu_map_kthread_run (kernel/bpf/cpumap.c:395)\n kthread (kernel/kthread.c:436)\n ret_from_fork (arch/x86/kernel/process.c:164)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\nKernel panic - not syncing: KASAN: panic_on_warn set ...(CVE-2026-81002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Force requesting ACS when tboot is enabled\n\nCurrently the conditions of requesting ACS in detect_intel_iommu()\ndon\u0026apos;t include tboot, leading to a possible misconfiguration with ACS\ndisabled (e.g. due to user opts) while iommu is later forced on by\ntboot_force_iommu().\n\nFix it by checking tboot in detect_intel_iommu().(CVE-2026-89448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: Fix CT limit teardown use-after-free\n\nPacket processing uses CT limit state under RCU, while netns teardown\nfrees that state under ovs_mutex. The CT limit pointer was neither removed\nfrom readers nor protected by a grace period, allowing packet processing to\ndereference the freed state.\n\nAn unprivileged user can trigger this bug from a user and network\nnamespace, causing a slab-use-after-free in ovs_ct_execute() when the\nnetns is torn down.\n\nPublish the CT limit pointer through RCU, remove it before teardown, and\nwait for readers before freeing its contents. Keep ovs_mutex around\nindividual CT limit updates, and use the RCU read-side lock while GET\ntraverses the RCU-protected limit lists.\n\nNetns teardown detaches the RCU-protected CT limit state in the pernet\n.pre_exit callback while holding ovs_mutex.  The pernet core guarantees an\nRCU grace period between the .pre_exit and .exit callbacks, so the .exit\ncallback completes the teardown without adding any extra synchronization.\n\nThe netlink command handlers do not need NULL checks because the userspace\nnetlink socket holds an active reference to its network namespace while a\nrequest is processed. The per-netns exit path therefore cannot run\nconcurrently with SET, DEL, or GET for that socket\u0026apos;s namespace.(CVE-2026-89488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject Read lists that exceed the page budget\n\nIndividual Read segment lengths are validated at decode time, but\nnothing prevents a requester from sending multiple segments whose\ncumulative length exceeds the rq_pages array budget. When one\nsegment fills the page array exactly, the runtime guard in\nsvc_rdma_build_read_segment() is bypassed because len reaches zero.\nA subsequent segment then accesses the NULL sentinel slot at\nrq_pages[rq_maxpages], resulting in a NULL pointer dereference during\nDMA mapping.\n\nAccumulate pages across all Read segments and reject the message at\ndecode time when the total would overflow the page budget.(CVE-2026-89528)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject inline replies that overflow the pull-up buffer\n\nAn RPC-over-RDMA client can request a reply, such as an NFS READ\npayload, without providing a Write list or a Reply chunk to carry\nit. When such a reply needs more scatter/gather entries than the\ndevice\u0026apos;s Send Queue supports, svc_rdma_pull_up_needed() selects\npull-up and svc_rdma_pull_up_reply_msg() linearizes the whole\nreply into sctxt-\u0026gt;sc_xprt_buf. That buffer is only sc_max_req_size\nbytes, while the reply on this path is bounded only by the client\u0026apos;s\nrequest, so svc_rdma_xb_linearize() copies past the end of the\nbuffer and corrupts adjacent slab memory. The oversized length is\nthen stored in sc_sges[0].length and posted, so the device also\nreads beyond the mapped region.\n\nThe SGE-exhaustion branch is the only pull-up path that can exceed\nthe buffer: the threshold branch pulls up only replies smaller\nthan RPCRDMA_PULLUP_THRESH, and replies that fit the device\u0026apos;s SGE\nbudget are sent directly without linearization. Make\nsvc_rdma_pull_up_needed() report -E2BIG when the reply it would\npull up cannot fit sc_max_req_size, and fail the request with\nERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping\nthe connection.\n\nThe helper no longer answers a simple yes/no question: it now\nreports pull-up, no pull-up, or -E2BIG for a reply too large to\nlinearize. Rename svc_rdma_pull_up_needed() to\nsvc_rdma_check_pull_up() so its name no longer implies a boolean\npredicate.(CVE-2026-89530)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: fix gssx_dec_option_array error path bugs\n\nFour coupled defects in the gssx XDR option-array decoder make the\nerror paths unsafe: a NULL deref in the caller, a refcount leak on\nthe decoded group_info, and a latent use-after-free that the leak\nfix would otherwise expose.\n\ngssx_dec_option_array() sets oa-\u0026gt;count = 1 before allocating\noa-\u0026gt;data.  If that allocation fails, -ENOMEM is returned with\noa-\u0026gt;count == 1 and oa-\u0026gt;data == NULL.  All other error paths jump\nto free_oa: which frees oa-\u0026gt;data and NULLs it but also leaves\noa-\u0026gt;count == 1.  The caller trusts the count:\n\n    gssp_accept_sec_context_upcall()\n      gssx_dec_accept_sec_context()\n        gssx_dec_option_array()        /* fails, count=1 data=NULL */\n      data = res.options.data[0].value /* NULL deref */\n\nIndependently, free_creds: releases the partially decoded svc_cred\nwith a bare kfree(creds).  gssx_dec_linux_creds() installs a\ngroups_alloc() result into creds-\u0026gt;cr_group_info; that object is\nkvmalloc-backed and refcounted, and only put_group_info() reaches\nkvfree().  A plain kfree(creds) drops the wrapper and leaks the\ngroup_info allocation.\n\nThe natural fix for the leak is to call free_svc_cred(creds) before\nkfree(creds), but free_svc_cred() invokes put_group_info() on\ncreds-\u0026gt;cr_group_info unconditionally when non-NULL.  The existing\nout_free_groups: path in gssx_dec_linux_creds() already called\ngroups_free() on that pointer without clearing it, so once\nfree_svc_cred() is wired in, the subsequent put_group_info() would\ntouch freed memory.\n\nFix all four together:\n\n  - Move the oa-\u0026gt;count = 1 assignment below the oa-\u0026gt;data allocation\n    so it is never set when oa-\u0026gt;data is NULL.\n  - Reset oa-\u0026gt;count to 0 at free_oa: so count and data stay\n    coherent and the caller sees an empty option array.\n  - Call free_svc_cred(creds) before kfree(creds) at free_creds:\n    so the refcounted cr_group_info is released.  free_svc_cred()\n    either NULL-guards each field explicitly (cr_group_info has\n    an if() check) or delegates to a helper that is NULL-safe\n    itself (kfree for the string fields, gss_mech_put() which\n    guards with if(gm) at gss_mech_switch.c:342), so it is safe\n    to call on a partially decoded svc_cred where only\n    cr_uid/cr_gid/cr_group_info have been written and everything\n    else is zero from kzalloc.\n  - In gssx_dec_linux_creds()\u0026apos;s out_free_groups: path, release\n    cr_group_info with put_group_info() rather than groups_free()\n    so the teardown matches free_svc_cred()\u0026apos;s refcount-aware path,\n    and clear the pointer so a later free_svc_cred() on the same\n    creds does not release it a second time.(CVE-2026-89544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: defer rq_argp and rq_resp free until after RCU grace period\n\nsvc_rqst_free() frees rqstp-\u0026gt;rq_argp and rqstp-\u0026gt;rq_resp synchronously\nvia kfree(), but defers the rqstp struct free via kfree_rcu().  After\nsvc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is\na window where RCU readers that started before list_del_rcu() can still\ntraverse the thread list and find the rqstp.  These readers (e.g.\nnfsd_nl_rpc_status_get_dumpit()) dereference rqstp-\u0026gt;rq_argp, which has\nalready been freed \u2014 a use-after-free.\n\nFix this by moving the kfree of rq_argp and rq_resp into an explicit\ncall_rcu() callback alongside the struct free.  Resources not accessed\nby RCU readers (bvec, buffer pages, scratch folio, auth_data) remain\nsynchronously freed.(CVE-2026-89545)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction\n\nmptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce,\nbackup, join_id, token and msk from the saved cookie entry when rebuilding\nthe request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it\ndoes not restore local_id, even though the SYN path saved it.\nsubflow_ulp_clone() then reads that uninitialized field and stores it as\nthe joined subflow\u0026apos;s address-ID. Because the request-sock slab is\nSLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale\nbyte of a previously freed request socket, which an off-path peer can\ninfluence by sending concurrent MP_JOIN SYNs. This corrupts the path\nmanager\u0026apos;s id-based subflow bookkeeping for the connection.\n\nRestore subflow_req-\u0026gt;local_id from the cookie entry, as done for the other\nfields.(CVE-2026-89554)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix UAF in check_new_map() on session freed during unlock\n\ncheck_new_map() iterates mdsc-\u0026gt;sessions[] and for each active session\ndrops mdsc-\u0026gt;mutex to perform per-session operations.  The forced-close\npath (rank removed from map) correctly takes a reference on s via\nceph_get_mds_session() before releasing mdsc-\u0026gt;mutex, but three other\npaths do not:\n\n  Path A (address changed):  mutex_unlock \u2192 mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n  Path B (reconnect):        mutex_unlock \u2192 send_mds_reconnect(mdsc, s)\n  Path C (active transition): mutex_unlock \u2192 mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n\nWithout the extra reference, another thread can acquire mdsc-\u0026gt;mutex\nduring the unlock window, call __unregister_session() which drops the\nlast reference on s, and free it.  The original thread then accesses\nfreed memory via s-\u0026gt;s_mutex.\n\nFix by adding ceph_get_mds_session(s) before each mutex_unlock and\nceph_put_mds_session(s) after the corresponding mutex_lock, matching\nthe pattern already used in the forced-close path.\n\nRace timeline (Path A):\n\n  Thread A (check_new_map)             Thread B (another map update\n    holds mdsc-\u0026gt;mutex                      or session teardown)\n  --------------------------           --------------------------\n  s = mdsc-\u0026gt;sessions[i]\n  (refcount == 1, held only by\n   sessions[] array)\n\n  mutex_unlock(\u0026amp;mdsc-\u0026gt;mutex)\n                               ---\u0026gt;    acquires mdsc-\u0026gt;mutex\n                                       __unregister_session(mdsc, s)\n                                         sessions[i] = NULL\n                                         ceph_put_mds_session(s)\n                                           refcount: 1 -\u0026gt; 0\n                                           kfree(s)  \u0026lt;--- freed!\n\n  mutex_lock(\u0026amp;s-\u0026gt;s_mutex)\n  UAF on freed s-\u0026gt;s_mutex(CVE-2026-89654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent lock owner use-after-free during client teardown\n\n__destroy_client() releases a client\u0026apos;s open owners, but a lock owner\nwhose only reference is a blocked lock (nbl) stays on\ncl_ownerstr_hashtbl.  client_has_state() does not count a bare owner,\nso DESTROY_CLIENTID can reach __destroy_client() with such owners\npresent.\n\n__destroy_client() then walks the table, calling remove_blocked_locks()\non each owner without a reference.  Freeing a blocked lock drops the\nowner reference held via flc_owner.  The per-net laundromat reaps\nblocked locks from nn-\u0026gt;blocked_locks_lru independently of client state.\nThe two paths share blocked_locks_lock only for the list splice, not\nthe owner\u0026apos;s lifetime.  The laundromat therefore frees the owner as\n__destroy_client() dereferences it, a NULL dereference in\nremove_blocked_locks().\n\nnfsd4_release_lockowner() holds a reference across the same call;\n__destroy_client() does not.  Hold cl_lock across the walk, taking a\nreference and unhashing each owner, then drop it before\nremove_blocked_locks() and nfs4_put_stateowner(), which take\nblocked_locks_lock and cl_lock.(CVE-2026-89662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE\n\nThe NFSv2 sattr decoder converts the wire useconds to nanoseconds in\nsvcxdr_decode_sattr():\n\n\tiap-\u0026gt;ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;\n\ntmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in\nunsigned long. On ILP32 that is 32 bits, and an out-of-range useconds\nvalue such as 4294968 wraps to tv_nsec == 704. The corruption therefore\nhappens during decode, before any proc function can inspect the value,\nand a later range check on tv_nsec would see an in-range result and\naccept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.\nNFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return\nfor a malformed time argument, and the check cannot move to the proc\nfunction the way the v3/v4 nsec range checks do.\n\nGuard the raw useconds before the multiplication and reject values\ngreater than 1000000. useconds == 1000000 is kept: it is the Sun\nconvention for \u0026quot;set to the current server time\u0026quot;, and the in-tree Linux\nNFSv2 client emits it in both the atime and the mtime field for a plain\ntouch / utimes(file, NULL) (see encode_sattr() and\nxdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000\nwould turn that common operation into a hard decode failure for both\nSETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap\non ILP32, so the Sun convention value passes through safely. Only\ngenuinely out-of-range values (\u0026gt; 1000000) are rejected. The atime and\nmtime guards are therefore symmetric.\n\nThe decoder only applied the Sun convention in the mtime block, which\nclears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a\nclient puts 1000000 in the atime field but not in the mtime field, the\natime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET\nset, so the bogus value reached the filesystem. Apply the convention in\nthe atime block as well, clearing ATTR_ATIME_SET so the server uses its\ncurrent time and ignores the value. Only ATTR_ATIME_SET is cleared there.\nThe mtime block keeps its existing behavior, where 1000000 means \u0026quot;set\nboth atime and mtime to now\u0026quot;.\n\n[ cel: various tweaks, addenda, and clean-ups ](CVE-2026-89665)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops\n\nA client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD\ncarrying an atime or mtime whose nseconds field is out of range. The\nvalue is well-formed on the wire and decodes cleanly into a valid\nuint32, but it is not a valid timespec64: tv_nsec must be less than\nNSEC_PER_SEC.\n\nNothing in the setattr path clamps it. notify_change() runs the time\nthrough timestamp_truncate(), which does not reduce tv_nsec below\nNSEC_PER_SEC when the filesystem supports nanosecond granularity\n(s_time_gran == 1), and the inode atime/mtime setters store it verbatim\n(only ctime is normalized, via inode_set_ctime_to_ts()). The\nun-normalized value then corrupts on-disk metadata: ext4\u0026apos;s\next4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which\noverflows the 32-bit extra field and clobbers the seconds-epoch bits, so\nthe stored seconds (and thus the year) are wrong on read-back. XFS with\nbigtime mis-stores the timestamp for the same reason.\n\nValidate the client-supplied atime/mtime in the proc handlers and return\nNFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL\nfor SETATTR and describes it as the error for a value the server \u0026apos;can\nnot store ... in its own representation\u0026apos;; the client maps it to EINVAL.\n\nChecking in the proc handlers, rather than in nfsd_setattr(), keeps the\nrejection in front of object creation. The create operations create the\nobject before nfsd_create_setattr() runs, so a late failure would leave\nthe new object behind and turn a non-idempotent request into a namespace\nchange that reports failure. The check is therefore done up front, for\nthe create operations before the object is created.\n\ntv_nsec is a long, so the comparison casts it to unsigned long (the same\nwidth) rather than to u32, matching timespec64_valid(). A u32 cast would\ntruncate on 64-bit; the unsigned long cast also rejects a value that\nbecame negative when an out-of-range u32 wire nseconds was assigned to a\n32-bit long.\n\nOnly client-supplied times are checked: SET_TO_SERVER_TIME requests\ncarry no client value. The sattrguard3 ctime is deliberately left alone:\nan out-of-range guard simply never matches the object\u0026apos;s ctime and yields\nNFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the\nprotocol-correct outcome rather than rejecting the request.(CVE-2026-89666)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: initialize copy-notify stateid before publishing it\n\nnfsd4_copy_notify() finished initializing the cpntf state after\nnfs4_alloc_init_cpntf_state() had already linked it into the\ns2s_cp_stateids IDR and the parent\u0026apos;s sc_cp_list, with cs_count == 1 (the\nmembership reference) and none held for the caller. A racing\nOFFLOAD_CANCEL (crafted cl_id == nn-\u0026gt;s2s_cp_cl_id plus the guessable\nso_id) could reach manage_cpntf_state() and free the entry, turning the\ncaller\u0026apos;s subsequent cpn_cnr_stateid read and cp_p_stateid/cp_p_clid\nwrites into use-after-free. The owning clientid was also only recorded\nafter publication, so it could not gate an ownership check in that window.\n\nRecord cp_p_stateid and cp_p_clid inside nfs4_alloc_init_cpntf_state()\nbefore nfs4_init_cp_state() publishes the entry, and return it with an\nextra reference. The caller reads the stateid under that reference and\ndrops it with nfs4_put_cpntf_state(); on a late error the laundromat\nreaps the entry.(CVE-2026-89669)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: gate nfs3 setacl by argp-\u0026gt;mask\n\nnfsd3_proc_setacl() calls set_posix_acl() unconditionally for both\nACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp-\u0026gt;acl_access and\nargp-\u0026gt;acl_default verbatim. The NFSv3 ACL decoder only populates\nthose pointers when the corresponding mask bit is set:\n\n    nfs3svc_decode_setaclargs()\n      if (args-\u0026gt;mask \u0026amp; NFS_ACL)    decode into acl_access\n      if (args-\u0026gt;mask \u0026amp; NFS_DFACL)  decode into acl_default\n      /* otherwise the pointer stays NULL (pc_argzero) */\n\n    nfsd3_proc_setacl()\n      set_posix_acl(.., ACL_TYPE_ACCESS,  argp-\u0026gt;acl_access)\n      set_posix_acl(.., ACL_TYPE_DEFAULT, argp-\u0026gt;acl_default)\n\nset_posix_acl(idmap, dentry, type, NULL) is the VFS \u0026quot;remove this\nACL type\u0026quot; operation. A NULL pointer that means \u0026quot;the client did not\nsend this arm\u0026quot; is therefore indistinguishable from \u0026quot;the client\nasked to remove this ACL\u0026quot;. A SETACL with mask=NFS_ACL silently\ndrops the directory\u0026apos;s default ACL; mask=0 drops both.\n\nThe sibling nfsd3_proc_getacl() already consults argp-\u0026gt;mask before\ntouching each arm; mirror that in setacl.\n\nFix by wrapping each set_posix_acl() call in the matching mask bit\ncheck and initializing error to 0 before inode_lock so that a\nrequest with neither bit set leaves the on-disk ACLs untouched and\nreturns nfs_ok. The out_drop_lock path and the unconditional\nposix_acl_release() at out: are preserved; both NULL-tolerate the\nskipped arms.(CVE-2026-89671)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget\n\nThe XDR buffer size calculation in nfsd4_ff_encode_layoutget() has\nmultiple errors that can result in either an out-of-bounds write or\nleaking uninitialized kernel memory to the client:\n\n - fh_len doesn\u0026apos;t account for XDR padding on the file handle data\n - uid and gid lengths use \u0026quot;8 + len\u0026quot; but xdr_encode_opaque() actually\n   writes \u0026quot;4 + xdr_align_size(len)\u0026quot; bytes\n - ds_len omits the flags and stats_collect_hint fields (8 bytes),\n   while len\u0026apos;s header constant overestimates by 8 bytes -- these\n   partially cancel but leave a net mismatch\n\nThe worst case occurs with short strings (e.g. uid=0, gid=0 with an\nodd-sized file handle), where the function writes up to 5 bytes past\nthe reserved XDR buffer. Conversely, when string lengths happen to be\n4-byte aligned, the reservation is too large and stale buffer content\nis sent to the client.\n\nFix this by breaking out every encoded field explicitly in the ds_len\ncalculation, using xdr_align_size() for all variable-length opaque\nfields, and correcting the header constants.(CVE-2026-89674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix UAF in async copy cancel and shutdown\n\nAn async copy could be freed or used after free while a teardown caller\n(OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the\ncopy kthread:\n\n  - find_async_copy() bumped copy-\u0026gt;refcount but left the copy on\n    clp-\u0026gt;async_copies, so the reaper\u0026apos;s cleanup_async_copy() could run\n    release_copy_files() concurrently with a cancel/shutdown caller. Both\n    put and NULL nf_src/nf_dst without a common lock, double-putting the\n    nfsd_file and freeing it early.\n\n  - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses\n    of the copy (nfsd_update_cmtime_attr() on copy-\u0026gt;nf_dst,\n    nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit\n    as \u0026quot;kthread done, skip kthread_stop()\u0026quot;, so a teardown caller ran\n    release_copy_files() -- which puts and NULLs nf_dst -- while the\n    kthread still dereferenced it (NULL/UAF).\n\n  - copy-\u0026gt;copy_task was never pinned. The one-shot kthread self-reaps on\n    return, so kthread_stop()\u0026apos;s get_task_struct() could touch a freed\n    task_struct.\n\n  - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a\n    reference only on the client, so a concurrent teardown could free\n    the copy while the CB_OFFLOAD callback was in flight.\n\nFix the teardown lifetime as a whole:\n\n  - find_async_copy() unlinks the copy (clear cp_clp, list_del_init)\n    under async_lock; the cancel, shutdown, and sb-cancel paths drop the\n    list-membership reference via nfs4_put_copy() after nfsd4_stop_copy().\n    Drop the now-redundant list_del fixup from cleanup_async_copy().\n\n  - Because unlinking hides the copy from the reaper, its\n    cleanup_async_copy() can no longer remove the copy\u0026apos;s s2s_cp_stateids\n    entry; the cancel/shutdown/sb-cancel paths now call\n    nfs4_free_copy_state() themselves (while cp_clp is still valid) so\n    the entry does not dangle at freed memory for the laundromat and\n    manage_cpntf_state() to dereference.\n\n  - Give the kthread its own reference, taken in nfsd4_copy() before\n    wake_up_process() and dropped at the end of nfsd4_do_async_copy();\n    call wake_up_process() before list_add().\n\n  - Pin the task_struct with get_task_struct() in nfsd4_copy(), released\n    in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread\n    exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now\n    always kthread_stop()s before release_copy_files(); completion is\n    still reported via NFSD4_COPY_F_COMPLETED, so\n    nfsd4_has_active_async_copies() is unaffected. Each teardown caller\n    removes the copy from clp-\u0026gt;async_copies first, so kthread_stop() runs\n    exactly once.\n\n  - Take a copy reference in nfsd4_send_cb_offload(), dropped in\n    nfsd4_cb_offload_release(). The kthread still holds its own reference\n    there, so the refcount_inc() cannot race the final free.\n\n  - Read cp_clp with smp_load_acquire() to pair with the unordered\n    set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst).(CVE-2026-89675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfsd_file leak on inter-server COPY setup failure\n\nWhen nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns\nnfserr_offload_denied directly, bypassing the out: label where\nrelease_copy_files() would drop the nf_dst reference taken by\nnfs4_preprocess_stateid_op(). Each failed inter-server COPY\nleaks one nfsd_file, pinning file/inode/dentry/vfsmount.\n\nFix by setting status and jumping to out: instead of returning\ndirectly.(CVE-2026-89680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix clock domain mismatch in clients_still_reclaiming()\n\nclients_still_reclaiming() computes a deadline from nn-\u0026gt;boot_time\n(CLOCK_REALTIME, ~1.7 billion) but compares it against\nktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot).\nThe comparison is always false \u2014 it would take ~54 years of uptime\nfor BOOTTIME to exceed the REALTIME-derived deadline.\n\nThis means any client can hold the server in grace indefinitely by\nsending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim\noperations for all other clients.\n\nAdd boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time\nand use it for the deadline computation. boot_time (CLOCK_REALTIME)\nis preserved for its cl_boot clientid-nonce role.(CVE-2026-89685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: block non-SAVEFH ops after FOREIGN PUTFH to prevent NULL deref\n\nWhen CONFIG_NFSD_V4_2_INTER_SSC is enabled, nfsd4_putfh() can return\nsuccess with fh_dentry and fh_export both NULL if fh_verify() returns\nnfserr_stale and putfh-\u0026gt;no_verify is true. The NFSD4_FH_FOREIGN flag\nis set, but the compound dispatch loop only uses this flag to bypass\nthe nfserr_nofilehandle check -- it does not prevent subsequent ops\nfrom running with a NULL fh_dentry.\n\nA remote client can exploit this by crafting a COMPOUND that includes\nan inter-SSC COPY (which causes check_if_stalefh_allowed() to set\nno_verify=true on the saved PUTFH) with an additional op inserted\nbetween the source PUTFH and SAVEFH. For example, SETATTR calls\nfh_want_write() which dereferences fh_export-\u0026gt;ex_path.mnt without\ncalling fh_verify() first, causing a NULL pointer dereference in the\nnfsd kthread.\n\nFix this by gating the dispatch loop: when NFSD4_FH_FOREIGN is set\nand fh_dentry is NULL, only OP_SAVEFH (needed for the inter-SSC flow)\nand ops with ALLOWED_WITHOUT_FH (which don\u0026apos;t need a resolved\nfilehandle) may proceed. All other ops receive nfserr_stale, per\nRFC 7862 Section 15.2.3 which specifies that foreign filehandle\nvalidation is deferred to the consuming operation and NFS4ERR_STALE\nreturned at that point.(CVE-2026-89696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlockd, nfsd: RCU-protect nlmsvc_ops dispatch\n\nnlmsvc_ops is published by nfsd_lockd_init() and cleared by\nnfsd_lockd_shutdown() with plain stores, while lockd dereferences\nit unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer\ntargets nfsd\u0026apos;s .rodata and the fopen/fclose callbacks live in nfsd\u0026apos;s\n.text, so a stale load after rmmod nfsd results in either a NULL\nderef or a module-text use-after-free.\n\nDeclare nlmsvc_ops as __rcu, publish via rcu_assign_pointer(), clear\nvia RCU_INIT_POINTER() + synchronize_rcu(). Add a struct module\n*owner field to nlmsvc_binding and pin the module across indirect\ncalls with try_module_get/module_put. When the binding is torn down,\nfall back to fput() to avoid leaking struct file references.(CVE-2026-89709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Initialize NVMe abort_work once at submission\n\nqla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on\npriv-\u0026gt;abort_work immediately before schedule_work(). INIT_WORK()\nreinitializes the work_struct, resetting its list head and clearing the\npending bit. If an abort is issued more than once for the same command\n(for example, concurrent transport teardown and a timeout-driven abort),\nthe second INIT_WORK() reinitializes a work item that is already queued,\nwhich can corrupt the workqueue list and lead to crashes or a looping\nworker.\n\nInitialize priv-\u0026gt;abort_work once at command submission, next to the\nexisting per-command spin_lock_init(\u0026amp;priv-\u0026gt;cmd_lock), and leave only\nschedule_work() in the abort paths. schedule_work() already does nothing\nwhen the work item is still pending, so a repeated abort no longer\ndisturbs an in-flight work item. The command is not returned to the\ntransport until the final kref_put()/release callback runs after\nabort_work has completed, so the work item is idle before priv is reused\nand the single submission-time INIT_WORK() is safe.(CVE-2026-89860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4.2: fix LAYOUTSTATS send buffer exhaustion\n\nencode_layoutstats_maxsz budgets XDR_QUADLEN(PNFS_LAYOUTSTATS_MAXSIZE),\ni.e. 256 bytes, for the layoutupdate4 body written by the layout driver.\nThe flexfiles record can exceed that.\n\nff_layout_encode_ff_layoutupdate() emits, per data server, a netaddr4,\nan nfs_fh4, two ff_io_latency4, an nfstime4 and a bool.  A data server\nwhose filehandle is NFS_MAXFHSIZE bytes long already accounts for 132 of\nthose bytes, and the two ff_io_latency4 at 64 bytes each, the nfstime4\nand the bool add a further 144, so the body passes 256 bytes before the\nnetaddr4 is encoded at all.  encode_layoutstats() additionally writes\nthe deviceid4 and the layoutupdate4 lou_type word, neither of which the\nmacro accounts for.\n\nThe filehandle and the address are both chosen by the server, through\nLAYOUTGET and GETDEVICEINFO, so it can drive the encoder past the\nend of the send buffer.  xdr_reserve_space() returns NULL once that\nhappens, and the two ff_layout_encode_io_latency() calls run with\ndss_info-\u0026gt;mirror-\u0026gt;lock held, so a NULL return there leaves the lock\npermanently held.\n\nRaise PNFS_LAYOUTSTATS_MAXSIZE to 384 so that the record fits inside the\nreservation.(CVE-2026-90103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt76x02: do not WARN on invalid rx descriptor length\n\nThe MPDU length in the rx descriptor comes from the hardware. In\nmonitor mode with the fcsfail filter enabled, the hardware passes up\ncorrupted frames, and a corrupted frame can report a length larger\nthan the received buffer. The bounds check correctly discards such\nframes, but its WARN_ON_ONCE wrapper means any over-the-air garbage\nframe taints the kernel, and panics it on the first such frame when\npanic_on_warn is set.\n\nDrop the WARN and discard the frame silently, matching what\ncommit c2d4c8723dbf (\u0026quot;mt76x2: remove some harmless WARN_ONs in tx\nstatus and rx path\u0026quot;) did for the neighboring rx and tx status paths.\n\nObserved immediately on rx with an MT7612U in fcsfail monitor mode\non a busy channel.(CVE-2026-90382)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/xive: propagate IPI init errors to prevent use-after-free\n\nWhen xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails),\nthe error path frees the global xive_ipis array.  However,\nxive_smp_probe() previously ignored this failure and proceeded to\ncall xive_setup_cpu_ipi(), which dereferences the already-freed\nxive_ipis pointer -- a use-after-free.\n\nNow that xive_smp_probe() returns int (previous patch), propagate\nthe error from xive_init_ipis() and xive_setup_cpu_ipi() through\nxive_smp_probe().  Check the return value in both pnv_smp_probe()\nand pSeries_smp_probe() so that IPI setup is aborted cleanly on\nfailure, avoiding the use-after-free.(CVE-2026-93260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix addr_filter_ranges lifetime\n\nLee Jia Jie reported that since event::addr_filter_ranges is used\nunder RCU, it should be RCU freed.(CVE-2026-93817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hidpp: fix potential UAF in hidpp_connect_event()\n\nIf input_register_device() fails, we call input_free_device(), but keep\nstale pointer to the old device in hidpp-\u0026gt;input, which could potentially\nlead to UAF. Fix that by resetting it to NULL before returning from\nhidpp_connect_event().(CVE-2026-93826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: add boundary checks in two places\n\nAdd boundary checks in acpi_ps_get_next_namestring() and\nacpi_ps_peek_opcode() to prevent out-of-bounds access.(CVE-2026-97444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()\n\nEnhance buffer validation in acpi_ut_walk_aml_resources() to prevent\nbuffer overflows.(CVE-2026-97445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add validation for node in acpi_ns_build_normalized_path()\n\nAdd validation for node in acpi_ns_build_normalized_path()\nto prevent use-after-free vulnerabilities.(CVE-2026-97448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: validate handler object type in two places\n\nACPICA: validate handler object type in acpi_ev_has_default_handler()\nand acpi_ev_find_region_handler().(CVE-2026-97450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)\n\nAdd overflow check for Index + Length to prevent integer overflow\nwhen calculating the truncation length. This prevents negative\nsize parameter being passed to memcpy().(CVE-2026-97451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Prevent adding invalid references\n\nPrevent adding references for local, argument, and debug objects\nin acpi_ut_copy_simple_object().(CVE-2026-97452)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: add boundary checks in acpi_ps_get_next_field()\n\nAdd boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds\naccess.(CVE-2026-97454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix use-after-free in acpi_ds_terminate_control_method()\n\nFix use-after-free issue in acpi_ds_terminate_control_method() by\nclearing references to method locals and arguments.(CVE-2026-97455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Skip vport under deletion in report ID acquisition\n\nqla24xx_report_id_acquisition() format-1 handling walks ha-\u0026gt;vp_list under\nvport_slock, takes a vref_count on the matching vport and calls\nqla_update_host_map() to register its port id.\n\nA vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then\nqla24xx_disable_vp() removes the vport from the host_map btree and zeroes\nvha-\u0026gt;d_id (RESET_AL_PA). The vport is only unlinked from vp_list later,\nin qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX)\nbut does not touch host_map. In the window in between, report ID\nacquisition can still find the vport on vp_list and call\nqla_update_host_map(); with d_id already zeroed it takes the\nbtree_insert32() path and re-inserts the dying vport into host_map.\nNothing cleans that entry afterwards, so once scsi_host_put() frees the\nvha a later host_map lookup dereferences freed memory.\n\nSkip a vport that has VPORT_DELETE set before taking the reference, so it\nis neither re-registered nor scheduled for DPC re-registration. This\nmirrors the existing guard in qla2x00_alert_all_vps().(CVE-2026-97531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use-after-free of qpair work on queue teardown\n\nThe response queue MSI-X handler qla2xxx_msix_rsp_q() schedules\nqla_do_work() via queue_work(ha-\u0026gt;wq, \u0026amp;qpair-\u0026gt;q_work). qla_do_work()\ndereferences the qpair (vha, rsp) and takes qpair-\u0026gt;qp_lock.\n\nDuring teardown, qla2xxx_delete_qpair() deletes the response queue, which\ncalls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and\nthe qpair. free_irq() waits for running hardirq handlers but does not\ncancel work already placed on ha-\u0026gt;wq. A still-pending q_work then runs\nqla_do_work() against the freed qpair and response queue, causing a\nuse-after-free. This is especially likely during full adapter teardown,\nwhere destroy_workqueue(ha-\u0026gt;wq) forces pending work to run after the queue\npairs have been freed.\n\nFlush the work item with cancel_work_sync() in qla25xx_free_rsp_que()\nafter free_irq() has released the interrupt (so no new work can be\nqueued) and before the response queue and qpair memory are freed (so the\nflushed handler still sees valid memory). Guard on rsp-\u0026gt;qpair and ha-\u0026gt;wq\nto match the INIT_WORK() condition and avoid operating on an\nuninitialized work_struct.(CVE-2026-97536)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-ctrls: validate HEVC tile counts\n\nThe stateless HEVC decoders read num_tile_columns_minus1 + 1 entries from\ncolumn_width_minus1[] and num_tile_rows_minus1 + 1 from row_height_minus1[]\nand use them as tile-loop bounds, but std_validate_compound() does not\nbound these u8 counts. Reject a V4L2_CTRL_TYPE_HEVC_PPS with tiling\nenabled whose tile counts exceed the uAPI array capacity, mirroring the\nexisting compound-control range checks.(CVE-2026-97576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mpls: clear inner_protocol when the last label is popped\n\nskb_mpls_push() records the pre-encapsulation network header once, gated\non !skb-\u0026gt;inner_protocol. skb_mpls_pop() never clears that record, so it\noutlives the encapsulation it describes.\n\nOpen vSwitch can then re-push MPLS onto a packet whose\ninner_network_header still points at the older, deeper offset: push a\nlabel, pop every label, recirculate (ovs_flow_key_update() re-derives\nkey-\u0026gt;eth.type and resets network_header, but leaves inner_*), then push\nagain. ovs_fragment() trusts the record:\n\n\tskb-\u0026gt;network_header = skb-\u0026gt;inner_network_header;\n\nso skb_network_offset() goes negative. The bound check is signed:\n\n\tif (skb_network_offset(skb) \u0026gt; MAX_L2_LEN)\n\na negative offset passes it, and prepare_frag() widens the value:\n\n\tunsigned int hlen = skb_network_offset(skb);\n\tmemcpy(\u0026amp;data-\u0026gt;l2_data, skb-\u0026gt;data, hlen);\n\nwhich is a ~4GiB memcpy out of a 30-byte per-CPU buffer.\n\nReproduced on v7.3-rc1. RDX is the truncated length, (unsigned int)(-8):\n\n  BUG: unable to handle page fault for address: ffffe8ffffc16000\n  #PF: supervisor write access in kernel mode\n  Oops: 0002 [#1] SMP KASAN NOPTI\n  RIP: 0010:memcpy+0x8/0x20\n  RDX: 00000000fffffff8 RSI: ffff888105d732db RDI: ffffe8ffffc16000\n   prepare_frag+0x3df/0x4e0\n   ovs_fragment+0x589/0x7e0\n   do_output+0x4ce/0x5e0\n   do_execute_actions+0x55d2/0x7b30\n   ovs_execute_actions+0xea/0x450\n\nSame root-cause shape as commit 975b5b067f52 (\u0026quot;ipv6: sr: restore network\nheader before routing and forwarding\u0026quot;): a stale network header offset\nreaching a consumer that widens it. Here it originates in the MPLS\npush/pop path.\n\nClear inner_protocol once the packet is no longer MPLS, so a later push\nre-records the current header. net/sched/act_mpls.c is the only other\nskb_mpls_pop() caller and gets the same fix; sch_frag.c saves and\nrestores inner_protocol around fragmentation in the same way OVS does.(CVE-2026-97612)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Set the trace clock before registering the histogram trigger\n\nhist_register_trigger() puts the trigger on the global named_triggers\nlist in cmd_ops-\u0026gt;init(), and only then sets the trace clock:\n\n\tif (data-\u0026gt;cmd_ops-\u0026gt;init) {\n\t\tret = data-\u0026gt;cmd_ops-\u0026gt;init(data);\n\t\tif (ret \u0026lt; 0)\n\t\t\tgoto out;\n\t}\n\n\tif (hist_data-\u0026gt;enable_timestamps) {\n\t\tret = tracing_set_clock(file-\u0026gt;tr, hist_data-\u0026gt;attrs-\u0026gt;clock);\n\t\tif (ret) {\n\t\t\thist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));\n\t\t\tgoto out;\n\t\t}\n\nThe clock string is not checked anywhere before that call, so a named\ntrigger using common_timestamp with an unknown clock fails after it has\nalready become findable. event_hist_trigger_parse() then frees it\nwithout taking it off the list, and the next lookup by name reads the\nfreed object:\n\n ~# cd /sys/kernel/tracing/events/sched/sched_switch\n ~# echo \u0026apos;hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus\u0026apos; \u0026gt; trigger\n bash: echo: write error: Invalid argument\n ~# echo \u0026apos;hist:name=foo:keys=common_pid\u0026apos; \u0026gt; trigger\n\n  BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0\n  Read of size 8 at addr ffff88800915d760 by task init/1\n   find_named_trigger+0xac/0xc0\n   hist_register_trigger+0xc1/0x900\n   event_hist_trigger_parse+0x3146/0x6af0\n   event_trigger_write+0xce/0x160\n  Freed by task 63:\n   kfree+0x154/0x420\n   trigger_kthread_fn+0xfd/0x160\n\nSet the clock before the trigger is registered, so that nothing which\ncan fail runs after it is published, the way commit 6f86bdeab633\n(\u0026quot;tracing: Fix bad hist from corrupting named_triggers list\u0026quot;) moved the\nregistration below the rest of the setup.\n\ntracing_set_filter_buffering() is reference counted, so the init failure\npath has to drop the reference that the clock block now takes first.(CVE-2026-97935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix fib6 walker UAF on seq stop\n\nipv6_route_iter_active() treats a walker in FWS_U at the table root as\nalready unlinked. fib6_del_route() can move a still-linked walker into\nthat same state when the current leaf is the last route at the root,\nso ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq\nprivate object can then be freed while it remains on\nnet-\u0026gt;ipv6.fib6_walkers. A later route deletion walks the dangling list\nand uses the freed walker.\n\nUse the list head as membership state and reinitialize it when\nunlinking. Keep the existing w-\u0026gt;node check so a never-started iterator\nwith a zeroed private object is not treated as linked.\n\nThe same stop helper is used by /proc/net/ipv6_route and by the BPF\nipv6_route iterator. The BPF show path only widens the race.(CVE-2026-97940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Don\u0026apos;t predict JMP32 pointer vs zero comparisons\n\nConsider the following program:\n\n        r1 = map_value;      /* low 32 bits are zero at runtime */\n        r6 = 0xdead000000000000;\n        if w1 != 0 goto l1;\n    l0: r1 += r6;\n        r2 = *(u64 *)(r1 + 0);\n        exit;\n    l1: r6 = 0;\n        goto l0;\n\nAt the moment is_branch_taken() reports the jump as always taken,\nbecause it does not distinguish between BPF_JMP and BPF_JMP32\ncomparisons when processing \u0026apos;if w1 != 0 ...\u0026apos;.(CVE-2026-98041)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: remove stale namespaces by NSID range during scan\n\nnvme_scan_ns_list() drops the stale namespaces in each gap in the\nreported NSID list one NSID at a time. Every iteration calls\nnvme_find_get_ns() to look the namespace up and removes it if it is\npresent. The loop runs once per NSID in the gap rather than once per\nnamespace actually present.\n\nNSIDs are 32-bit, so a target with a sparse NSID space can make a\nsingle gap spin the loop billions of times with nothing to remove.\n\n  watchdog: BUG: soft lockup - CPU#4 stuck for 26s!\n  Workqueue: nvme-wq nvme_scan_work [nvme_core]\n  RIP: 0010:__srcu_read_unlock+0xb/0x20\n  Call Trace:\n   nvme_find_get_ns+0x7d/0xb0 [nvme_core]\n   nvme_scan_ns_list+0xe8/0x280 [nvme_core]\n   nvme_scan_work+0x18a/0x280 [nvme_core]\n   process_one_work+0x197/0x380\n   worker_thread+0x2fe/0x410\n   kthread+0xe0/0x100\n\nRename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range()\nand give it an open (start, end) NSID range. ctrl-\u0026gt;namespaces is\nsorted by NSID, so the whole gap is dropped in a single walk that\nstops once end is reached. This bounds the work by the namespaces\nthat are present instead of by the size of the gap.(CVE-2026-98056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: restore network header before routing and forwarding\n\nipv6_srh_rcv() runs with skb-\u0026gt;data at the Segment Routing Header (SRH)\nwhile skb_network_header() points at the IPv6 header.\n\nWhen segments_left \u0026gt; 0, ipv6_srh_rcv() previously restored the skb-\u0026gt;data\nposition by pushing sizeof(struct ipv6hdr), assuming the SRH immediately\nfollowed the fixed IPv6 header. If another extension header (such as a\nHop-by-Hop options header) precedes the SRH, skb_network_offset()\nremained negative.\n\nThis led to two problems:\n1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes\n   __skb_flow_dissect() which passes the negative skb_network_offset()\n   to flow dissection, breaking BPF and C flow dissector logic.\n2. If forwarded via ip6_forward() or redirected via act_mirred, downstream\n   handlers (like sch_fragment() or neighbour output) pass the negative\n   offset as an unsigned length, triggering OOB memcpy or buffer overflows.\n\nFix this by pushing -skb_network_offset(skb) before routing, ensuring\nskb_network_offset(skb) is 0 for route lookup / flow dissection as well as\ndownstream forwarding. On the loopback path, pull skb_transport_offset(skb)\nto restore skb-\u0026gt;data to the SRH before looping back.(CVE-2026-98096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan\n\nl2cap_new_connection() sets default value of channel mode to match the\nparent channel.  l2cap_le_connect_req() left this at the default, and\ncreated L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that\nmode.  This causes FLAG_DEFER_SETUP channels to reply to\nL2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect.\n\nIt can also result to stack OOB write (of l2cap_alloc_cid determined\nvalues) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not\nlimit maximum number of deferred channels or check for duplicate ident.\n\nFix by setting chan-\u0026gt;mode correctly in l2cap_le_connect_req().\n\nAlso check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE\ninstead of OOB write to make it less brittle.(CVE-2026-98108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: encrypted: fix integer overflow of datablob_len\n\nencrypted_key_alloc() stores datablob_len in a u16. It is computed from\nmultiple string and payload lengths. If the result exceeds U16_MAX, the\nassignment truncates the allocation size. KASAN reports a 32760-byte\nslab-out-of-bounds write when __ekey_init() copies the master key\ndescription into the undersized buffer.\n\nThe total payload length stored in key-\u0026gt;datalen is also a u16. Use\ncheck_add_overflow() to reject values that do not fit either destination,\nand use kzalloc_flex() for the flexible-array allocation.(CVE-2026-98222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: fix refcount bug in iwpm_get_nlmsg_request()\n\niwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail()\nmaking it accessible to global list where another CPU can kref_get()\non nlmsg_request causing a refcount \u0026quot;addition on 0\u0026quot; bug. Fix this\nby initializing kref _before_ list_add_tail() so refcount for\nnlmsg_request can be incremented/decremented normally. In addition,\nalso initialize every field before list_add_tail().(CVE-2026-98252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Serialize join and leave on copy_to_user failure\n\nrdma_join_multicast() queues RoCE work that later reads the ucma_multicast\nthrough event-\u0026gt;param.ud.private_data, then list_add()s the CMA multicast\nat the head of id_priv-\u0026gt;mc_list. rdma_leave_multicast() matches only by\nsockaddr and destroys the first hit.\n\nucma_process_join() used to drop ctx-\u0026gt;mutex after a successful join and\nretake it only if copy_to_user() failed. Two concurrent JOIN_MCAST calls\nwith the same address can therefore insert a second CMA entry before the\nfirst thread\u0026apos;s leave. leave then cancels the newer work and the older\nworker still dereferences the ucma_multicast that the first thread frees.\n\nKeep ctx-\u0026gt;mutex held from rdma_join_multicast() through copy_to_user() and,\non -EFAULT, through rdma_leave_multicast() so leave cannot miss this join.\nDo not leave if join itself failed: that path never published this address\non mc_list, and a leave-by-addr would destroy an earlier successful join.(CVE-2026-98253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lock the socket in sock_gettstamp()\n\nsk-\u0026gt;sk_flags must only be changed while holding the socket lock,\nbecause sock_set_flag() and sock_reset_flag() use non atomic\noperations (__set_bit() and __clear_bit()).\n\nsock_gettstamp() is one of the last places where a bit of sk-\u0026gt;sk_flags\nis changed from a syscall without owning the socket lock, through\nsock_enable_timestamp(sk, SOCK_TIMESTAMP).\n\nsk_set_memalloc() and sk_clear_memalloc() also change sk-\u0026gt;sk_flags\nwithout the socket lock, but their callers (nbd, iscsi_tcp, nvme-tcp,\nsunrpc, wireguard) need a careful audit, this will be addressed in a\nseparate patch.\n\nJungwoo Lee and Wongi Lee reported an UDP socket use-after-free\ncaused by this bug: a SIOCGSTAMPNS_NEW ioctl racing with bind()\ncan cancel the SOCK_RCU_FREE bit that udp_lib_get_port() just set,\nbecause both threads perform a read-modify-write on the same word.\n\n  CPU 0 (bind)                        CPU 1 (SIOCGSTAMPNS_NEW)\n  --------------------------------    ----------------------------\n  read sk_flags = F                   read sk_flags = F\n  compute F | BIT(SOCK_RCU_FREE)      compute F | BIT(SOCK_TIMESTAMP)\n  store F | BIT(SOCK_RCU_FREE)\n  sk_add_node_rcu(sk, ...)\n                                      store F | BIT(SOCK_TIMESTAMP)\n\nAfter the lost update, SOCK_RCU_FREE is clear while the socket is\nvisible to lockless UDP receive lookups. sk_destruct() then frees\nthe socket immediately instead of waiting for a RCU grace period,\nwhile the receive path still holds a reference-less pointer to it:\n\n BUG: KASAN: slab-use-after-free in ipv4_pktinfo_prepare+0x30/0x410\n Read of size 8 at addr ffff888008806610 by task exploit/207\n CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1\n  ipv4_pktinfo_prepare+0x30/0x410\n  udp_queue_rcv_one_skb+0x51c/0x1180\n  udp_unicast_rcv_skb+0x109/0x350\n  ip_protocol_deliver_rcu+0x14b/0x310\n  ip_local_deliver_finish+0x29d/0x390\n  ip_local_deliver+0x24d/0x2a0\n\nOnly grab the socket lock when SOCK_TIMESTAMP has to be set,\nto keep the common case lockless.(CVE-2026-98276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: wait for deferred control PDU completions before releasing the connection\n\nisert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and\nISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns.  The work\nitem then runs isert_completion_put() -\u0026gt; isert_put_cmd(), which reads\nisert_conn-\u0026gt;conn and takes conn-\u0026gt;cmd_lock.\n\nNothing orders that work item against teardown.  isert_wait_conn() queues\nisert_release_work, which frees isert_conn, and iscsit_close_connection()\nfrees the iscsit_conn right after it returns, so the queued work can run\nagainst freed memory.\n\nCount the deferred control PDU completions per connection and let\nisert_wait_conn() wait for them before the release work is queued.\n\nISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs\niscsit_logout_post_handler(), which ends up waiting for\nconn-\u0026gt;conn_wait_comp, and that completion is only sent by\niscsit_close_connection() after it has called iscsit_wait_conn().\nWaiting for it here would deadlock.  Its wait stays the existing\nisert_wait4logout().\n\nThe splat below is from a kernel with tracing printk()s and an msleep(200)\ninjected into isert_do_control_comp() to widen the window:\n\n  BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620\n  Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182\n\n  CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G    B               7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy)\n  Tainted: [B]=BAD_PAGE\n  Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  Workqueue: isert_comp_wq isert_do_control_comp\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x53/0x70\n   print_report+0xd0/0x630\n   ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n   ? _raw_spin_unlock_irqrestore+0x3e/0x70\n   ? isert_put_cmd+0x53d/0x620\n   kasan_report+0xce/0x100\n   ? isert_put_cmd+0x53d/0x620\n   isert_put_cmd+0x53d/0x620\n   ? isert_completion_put+0x305/0x330\n   ? isert_do_control_comp+0x2ef/0x310\n   process_one_work+0x633/0x1030\n   ? assign_work+0x11d/0x370\n   worker_thread+0x45b/0xd10\n   ? __pfx_worker_thread+0x10/0x10\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x2c6/0x3b0\n   ? recalc_sigpending+0x15c/0x1e0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x36e/0x5a0\n   ? __pfx_ret_from_fork+0x10/0x10\n   ? __switch_to+0x572/0xdd0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 48:\n   kasan_save_stack+0x33/0x60\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0x8f/0xa0\n   __kmalloc_cache_noprof+0x158/0x370\n   isert_cma_handler+0x1e3/0x2ae0\n   cma_cm_event_handler+0x3e/0x240\n   cma_ib_req_handler+0x17d9/0x4490\n   cm_process_work+0x41/0x330\n   cm_work_handler+0x5727/0xc160\n   process_one_work+0x633/0x1030\n   worker_thread+0x45b/0xd10\n   kthread+0x2c6/0x3b0\n   ret_from_fork+0x36e/0x5a0\n   ret_from_fork_asm+0x1a/0x30\n\n  Freed by task 184:\n   kasan_save_stack+0x33/0x60\n   kasan_save_track+0x14/0x30\n   kasan_save_free_info+0x3b/0x60\n   __kasan_slab_free+0x43/0x70\n   kfree+0x121/0x380\n   iscsit_close_connection+0x7cf/0x1e60\n   iscsit_take_action_for_connection_exit+0x1b6/0x360\n   iscsi_target_tx_thread+0x472/0x690\n   kthread+0x2c6/0x3b0\n   ret_from_fork+0x36e/0x5a0\n   ret_from_fork_asm+0x1a/0x30(CVE-2026-98357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Reject unregistering netdevs in ib_get_eth_speed\n\nib_device_get_netdev() intentionally returns a referenced net_device even\nwhen it is unregistering, so matching and cleanup callers can still find\nthe association. The reference keeps struct net_device allocated, but does\nnot guarantee that the device remains operational.\n\nib_get_eth_speed() uses the returned device operationally by invoking its\nethtool callback. Although that call is made under RTNL, the function does\nnot verify the registration state first. An asynchronous RDMA port query\ncan therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit\nhave completed.\n\nCheck for NETREG_REGISTERED while holding RTNL and return -ENODEV for a\ndevice which is being unregistered. Keeping RTNL across the check and the\nethtool operation prevents unregister from starting between them.\n\nKeep the speed fallback and warning under RTNL as well, so the warning can\nsafely read netdev-\u0026gt;name. Drop the netdev reference before releasing RTNL\nonce all accesses to the device are complete.(CVE-2026-98359)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access\n\nmr_check_range() validates that [iova, iova+length) falls within the\nregistered MR range using wraparound-prone arithmetic:\n\n    if (iova \u0026lt; mr-\u0026gt;ibmr.iova ||\n        iova + length \u0026gt; mr-\u0026gt;ibmr.iova + mr-\u0026gt;ibmr.length)\n\nA remote peer can craft an RDMA-Write/Read RETH so that iova + length\nwraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the\ncheck. rxe_mr_iova_to_index() then computes a huge index (int idx, only\nguarded by WARN_ON) and rxe_mr_copy_xarray() dereferences\nmr-\u0026gt;page_info[huge], causing an out-of-bounds read/write and a kernel\noops that is triggerable by an unauthenticated remote peer.\n\nRewrite the check in overflow-safe form; the first two clauses guarantee\nthat the subsequent subtractions do not underflow:\n\n    if (iova \u0026lt; mr-\u0026gt;ibmr.iova ||\n        length \u0026gt; mr-\u0026gt;ibmr.length ||\n        iova - mr-\u0026gt;ibmr.iova \u0026gt; mr-\u0026gt;ibmr.length - length)\n\nWith the fix, mr_check_range() returns -EINVAL for the crafted iova and\nthe responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB.(CVE-2026-98365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: validate checksum_start before completing checksum\n\nIf a packet with bad checksum metadata gets into the ipv4 stack,\nskb_checksum_help can corrupt the network header and cause a bunch of\nmischief.\n\nThis was discovered and reported by Paulos, and has been reporoduced\nby others independently since.\n\nWe really shouldn\u0026apos;t allow such packets in, but as a defence\nin depth measure, let\u0026apos;s also check before we complete the checksum.\n\nA more complete validation at input is forthcoming, but needs more work.(CVE-2026-99999)",
  "id": "OESA-2026-4591",
  "modified": "2026-10-29T09:03:19Z",
  "published": "2026-10-29T09:03:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4591"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40233"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71152"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43075"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53146"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53253"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53254"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53349"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64277"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64363"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64532"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64541"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74498"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74507"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74581"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74630"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80714"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89448"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89488"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89528"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89530"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89544"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89545"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89654"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89662"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89665"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89666"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89669"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89671"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89680"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89685"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90103"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90382"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93260"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93826"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97444"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97445"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97448"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97450"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97451"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97452"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97454"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97455"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97531"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97536"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97576"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97612"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98041"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98056"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98108"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98222"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98253"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98276"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98357"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98359"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98365"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99999"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-40233",
    "CVE-2025-71152",
    "CVE-2026-43075",
    "CVE-2026-53146",
    "CVE-2026-53189",
    "CVE-2026-53253",
    "CVE-2026-53254",
    "CVE-2026-53349",
    "CVE-2026-63833",
    "CVE-2026-64277",
    "CVE-2026-64363",
    "CVE-2026-64532",
    "CVE-2026-64541",
    "CVE-2026-68479",
    "CVE-2026-74498",
    "CVE-2026-74507",
    "CVE-2026-74508",
    "CVE-2026-74581",
    "CVE-2026-74583",
    "CVE-2026-74630",
    "CVE-2026-74739",
    "CVE-2026-80590",
    "CVE-2026-80681",
    "CVE-2026-80714",
    "CVE-2026-81001",
    "CVE-2026-81002",
    "CVE-2026-89448",
    "CVE-2026-89488",
    "CVE-2026-89528",
    "CVE-2026-89530",
    "CVE-2026-89544",
    "CVE-2026-89545",
    "CVE-2026-89554",
    "CVE-2026-89654",
    "CVE-2026-89662",
    "CVE-2026-89665",
    "CVE-2026-89666",
    "CVE-2026-89669",
    "CVE-2026-89671",
    "CVE-2026-89674",
    "CVE-2026-89675",
    "CVE-2026-89680",
    "CVE-2026-89685",
    "CVE-2026-89696",
    "CVE-2026-89709",
    "CVE-2026-89860",
    "CVE-2026-90103",
    "CVE-2026-90382",
    "CVE-2026-93260",
    "CVE-2026-93817",
    "CVE-2026-93826",
    "CVE-2026-97444",
    "CVE-2026-97445",
    "CVE-2026-97448",
    "CVE-2026-97450",
    "CVE-2026-97451",
    "CVE-2026-97452",
    "CVE-2026-97454",
    "CVE-2026-97455",
    "CVE-2026-97531",
    "CVE-2026-97536",
    "CVE-2026-97576",
    "CVE-2026-97612",
    "CVE-2026-97935",
    "CVE-2026-97940",
    "CVE-2026-98041",
    "CVE-2026-98056",
    "CVE-2026-98096",
    "CVE-2026-98108",
    "CVE-2026-98222",
    "CVE-2026-98252",
    "CVE-2026-98253",
    "CVE-2026-98276",
    "CVE-2026-98357",
    "CVE-2026-98359",
    "CVE-2026-98365",
    "CVE-2026-99999"
  ]
}